IMS Logo

IMS Resource List Interoperability
Conformance Requirements

Version 1.0 Final Specification

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Resource List Interoperability Conformance Requirements
Revision: 8 July 2004

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2004 IMS Global Learning Consortium. All Rights Reserved.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.


Table of Contents


1. Introduction
1.1 RLI Specification Components
1.1.1 Information Model
1.1.2 XML/WSDL Binding
1.1.3 Best Practice and Implementation Guide
1.1.4 Conformance Requirements (this document)
1.2 Nomenclature
1.3 References
1.4 Localization

2. Conformance Statements
2.1 Information Model
2.1.1 Data
2.1.2 Processors - Receivers of Data
2.1.3 Processors - Transmitters of Data
2.2 XML Bindings
2.2.1 General
2.2.2 Instances
2.2.3 Processors - Receivers of Data
2.2.4 Processors - Creators of Data
2.2.5 Processors - Transmitters of Data
2.3 Making Conformance Claims

About This Document
List of Contributors

Revision History

Index


1. Introduction

This section is not normative.

1.1 RLI Specification Components

This document is the IMS Resource List Interoperability (RLI) Specification version 1.0. As such, it forms one of the set that comprises the specification, each with distinct scope.

1.1.1 Information Model

Describes the core aspects of the specification and contains parts that are normative for any binding claiming to use this Information Model. It contains details of: semantics, structure, data types, value spaces, multiplicity, and obligation (i.e., whatever mandatory or optional).

1.1.2 XML/WSDL Binding

Describes a binding of the Information Model to XML version 1.0, as well as binding of the abstract service interface to web services expressed as WSDL. These bindings are normative for any XML instance that claims to use these bindings, whether by reference to the specification or by declaration of the namespace reserved by the specification. In cases of error or omission, the Information Model takes precedence. The IMS RLI Binding is released with a control document using W3C XML Schema 1.0 that should be used in implementation.

1.1.3 Best Practice and Implementation Guide

Provides non-normative guidance on application of the Information Model and Binding. This includes reference to existing practice in handling information that this specification seeks to support and guidance on practices that will promote interoperability and durability. It also includes examples to illustrate how the conceptual framework maps to practical uses, and to identify the relationship between this specification and related IMS specifications. Implementers are encouraged, but not required, to follow guidance in this part of the specification.

1.1.4 Conformance Requirements (this document)

Provides a set of testable statements that may be used in relation to applications of the Information Model and Binding. These statements may form a basis of formal conformance testing and certification or informal assertions. This document makes no statement about the formal processes or methods of certification, it only deals with criteria.

1.2 Nomenclature

The terms defined in the RFC 2119 (IETF RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels) are used with the meaning there defined in any section of this document stated to be "normative".

1.3 References

[RLI, 04a] IMS Resource List Interoperability Information Model v1.0, A.Jackl, IMS Global Learning Consortium, Inc., July 2004
[RLI, 04b] IMS Resource List Interoperability Binding v1.0, A.Jackl, IMS Global Learning Consortium, Inc., July 2004
[RLI, 04c] IMS Resource List Interoperability Best Practice and Implementation Guide v1.0, A.Jackl, IMS Global Learning Consortium, Inc., July 2004
[IEEE LOM] IEEE 1484-12:2002, Standard for Learning Object Metadata, http://ltsc.ieee.org
[IMSBUND] Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications, v1.0, B.Olivier, M.McKell, IMS Global Learning Consortium, Inc., August 2001.
[IMSPLID] IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook v1.0, IMS Global Learning Consortium, Inc., April 2001.
[RFC 1766] Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc1766.txt
[RFC 2119] Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt
[RFC 2396] Uniform Resource Identifiers (URI): Generic Syntax, http://www.ietf.org/rfc/rfc2396.txt
[RFC 2732] Format for Literal IPv6 Addresses in URLs, http://www.ietf.org/rfc/rfc2732.txt
[W3C XML] W3C XML 1.0 Specification, http://www.w3.org/TR/1998/REC-xml-19980210

1.4 Localization

Whereas the Information Model used plain formatted English terms for element names, since the language of the specification is English, the Binding uses tokens for elements names. These are derived from the Information Model element names. Translators of the Information Model may change the names used in that document but they must map to XML Binding element names exactly as presented in the specification; translation of XML element names is not permitted. This restriction will ensure machine-level interoperability of data.

Annotations and comment strings in the official IMS RLI XSD files appear in at least US English. Annotations and comments in other languages may be added as deemed necessary by IMS stakeholders and such a revision must only be published by IMS. Since interoperability depends on trustworthy binding instances, only exact copies of the official IMS binding instance should be publicly circulated. Any entity other than IMS that needs localized annotations or comments should create a separate document with such annotations and comments, and reference the official IMS binding instance rather than circulating a binding instance that is different to, but could be believed to be identical to, the official IMS version.

The Binding document may be translated except for the representations of:

  • binding structure names
  • binding structure value spaces
  • file naming syntax and examples
  • binding namespace URI
  • binding file path representation

The essence of this section is that XML instance expressing the same information should not differ if created by readers of different localized versions of this specification.

Localization of this document shall not cause any change in specification version numbering or binding revision instance numbering.

2. Conformance Statements

This section is normative.

Conformance statements are divided into sections for the Information Model and for the Binding. It is conceptually cleaner to identify statements that are binding independent. Statements are broken out into those that apply to the Information Model and those that apply to the Binding.

Conformances statements are made at a syntactic level only - i.e., no statement attempts to provide criteria for the data being meaningful.

2.1 Information Model

2.1.1 Data

  1. Data types must conform to the specifications of the Information Model.
  2. Value spaces must conform to the specifications of the Information Model. This includes but is not necessarily limited to the requirements that:
    • Character strings must conform to the requirements of ISO /IEC 10646-1:2000.
    • Characters strings that are restricted to the specifications of RFC2396 conform to the requirements of that RFC (as amended by RFC 2732).
  3. Extensions to the Information Model may be used provided that in all other respects the requirements of this document are met.
  4. Langstring-containing elements must not contain more than one langstring where the same language is identified (including the case of no language being identified).
  5. The language property of a langstring must conform to the requirements of RFC1766.

2.1.2 Processors - Receivers of Data

  1. Processors must handle data that is valid in respect to the mandatory requirements of sub-section 2.1.1 of this document.
  2. Processors must handle at least the number of characters in elements as defined in the OCL within the Information Model [RLI, 04a] (see sub-section 4.8).
  3. Processors should not require the presence of extensions.
  4. A processor may reject data where an optional element has not been used only if the data-exchanging parties both agree to an additional set of restrictions (an "application profile").
  5. Arbitrary content of the <metadata> element must be accepted (i.e., must not cause errors or process abortion).
  6. Contents of the meta-data element may be ignored.

2.1.3 Processors - Transmitters of Data

If data is relayed without change of content then the processor may be described as a transmitter of data. The content is not dependent upon the binding.

2.2 XML Bindings

2.2.1 General

  1. A conformant XML 1.0 RLI instance or processor must conform to the requirements of sub-section 2.1.1 of this document.
  2. WSDL behavior references will evolve as more implementations of the RLI specification arise.

2.2.2 Instances

  1. A conformant RLI XML instance must conform to the W3C XML 1.0 Specification (http://www.w3.org/TR/1998/REC-xml-19980210).
  2. A conformant RLI XML instance must declare the namespace "http://www.imsglobal.org/xsd/imsrli_v1p0".
  3. A conformant RLI XML instance should associate the namespace with a control document such that it can be validated.
    • By referencing a control document located on the IMS website under http://www.imsglobal.org/xsd/.
    • Or by referencing a local copy of this control document.
  4. A conformant RLI XML instance must be valid according to the XSD and WSDL control documents located on the IMS website at http://www.imsglobal.org/.
  5. A conformant RLI XML instance should be encoded using UTF-8.
  6. Any extensions are expressed as described in IMS RLI XML/WSDL Binding v1.0.
  7. If meta-data is present then it must be included as described in IMS RLI XML/WSDL Binding v1.0.

2.2.3 Processors - Receivers of Data

  1. Processors must handle data that is valid according to the mandatory requirements of sub-section 2.1.1 and sub-section 2.1.2 of this document.
  2. Processors may reject data that does not conform to the mandatory requirements of sub-section 2.1.1 and sub-section 2.1.2 of this document and should emit a warning if invalid data is processed.
  3. Processors must handle UTF-8 encoded data.
  4. Processors may handle data encoded in schemes other than UTF-8.

2.2.4 Processors - Creators of Data

  1. Processors must create data that is valid according to the mandatory requirements of sub-section 2.1.1 and sub-section 2.1.2 of this document.

2.2.5 Processors - Transmitters of Data

  1. The transmitted XML instance should be lexically identical.
  2. The transmitted XML instance may be lexically different but must be equivalent as an XML Information Set (http://www.w3.org/TR/2001/REC-xml-infoset-20011024).

2.3 Making Conformance Claims

This section is not normative and should not be interpreted to guide any formal certification or testing process; it provides some outline recommendations for making unverified assertions.

Claims of conformance should provide a statement, detailing the level of conformance, substantially similar to the information outlined below.

Conformance would typically be presented in two parts:

  • Conformance summary - this is a summary that shows, in colloquial terms, the capabilities of a particular implementation with respect to the IMS RLI Specification;
  • Interoperability statement - this is a detailed technical checklist that identifies all of the feature capabilities of the implementation in terms of the IMS RLI Conformance Requirements Specification (this document).

The "conformance summary" should include clear indications of the classes of vocabulary that are supported and include comment on semantic issues (i.e., meaningfulness of data).

The form of an interoperability statement will probably vary but should at least attempt to identify all of the conformance statements in this document and for identifying:

  • Statements using "must" or "shall" where the clause is not implemented or incompletely implemented;
  • Statements using "should" or "should not" where an alternative to the clause is implemented (the justification for the deviation may be helpful);
  • Statements using "must not" or "shall not" where the clause is implemented;
  • Statements of option that an implementation requires (for example elements that are optional in RLI being required);
  • Where extensions have a functional role and what that role is.

Specific applications are expected to define more detailed application profiles, especially in relation to use of meta-data.

About This Document

Title IMS Resource List Interoperability Conformance Requirements
Editor Mladen Maljkovic (WebCT)
Team Co-Leads Oliver Heyer (UC Berkeley), Mladen Maljkovic (WebCT)
Version 1.0
Version Date 08 July 2004
Status Final Specification
Summary This document describes the Conformance Statements applicable to the Resource List Interoperability specification.
Revision Information July 2004
Purpose This document has been approved by the IMS Technical Board and is made available for adoption.
Document Location http://www.imsglobal.org/rli/rliv1p0/imsrli_confv1p0.html

To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=22

List of Contributors

The following individuals contributed to the development of this document:

Name Organization
Phil Barker CETIS
Kerry Blinco DEST
Lorna Campbell CETIS
Norm Friesen Industry Canada
Oliver Heyer University of California, Berkeley
Nancy Hoebelheinrich Stanford University
Alex Jackl IMS Global Learning Consortium, Inc.
Mladen Maljkovic WebCT
Jon Mason DEST
Howard Noble Sentient
Claude Ostyn Click2learn, Inc.
Dan Rehak Carnegie Mellon
Scott Wilson CETIS

Revision History

Version No. Release Date Comments
Base Document 1.0 11 November 2003 Initial version of the Resource List Interoperability specification.
Public Draft 1.0 31 May 2004 Public Draft version of the Resource List Interoperability Conformance Requirements.
Final Specification 1.0 08 July 2004 This is the formal Final version of the IMS Resource List Interoperability Conformance Requirements.

Index

B
Behavior 1
Binding 1, 2, 3

C
Conformance 1, 2

I
IEEE 1
IMS Specifications
Learner Information Package 1
Resource List Interoperability 1, 2, 3, 4
Resources List Interoperability 1
Interoperability 1, 2, 3
ISO 1
 

L
LOM 1

M
Meta-data 1, 2, 3

N
Namespace 1, 2, 3
Normative 1, 2, 3

P
Profile 1

R
Resource list 1, 2
Resources list 1
RFC 1, 2, 3

S
Services 1
Structure 1, 2

U
URI 1

V
Vocabulary 1

W
W3C 1, 2, 3

X
XML 1, 2, 3, 4
XSD 1
 

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Resource List Interoperability Conformance Requirements ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS would appreciate receiving your comments and suggestions.

Please contact IMS through our website at http://www.imsglobal.org

Please refer to Document Name:
IMS Resource List Interoperability Conformance Requirements Revision: 08 July 2004