IMS Vocabulary Definition Exchange 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 Vocabulary Definition Exchange Conformance Requirements
Revision: 23 February 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.
1.1 IMS Vocabulary Definition Exchange Specification Components
1.1.1 Information Model
1.1.2 XML Binding
1.1.3 Best Practices and Implementation Guide
1.1.4 Conformance Requirements (this document)
2. Conformance Statements
2.1 Information Model
2.1.2 Processors - Receivers of Data
2.1.3 Processors - Creators of Data
2.1.4 Processors - Transmitters of Data
2.2 XML 1.0 Binding
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
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., whether mandatory or optional).
Describes a binding of the Information Model to XML version 1.0 and is normative for any XML instance that claims to use this binding, 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 VDEX XML Binding is released with a control document using W3C XML Schema 1.0 that should be used in implementations.
Provides non-normative guidance on application of the Information Model and XML 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.
Provides a set of testable statements that may be used in relation to applications of the Information Model and XML Binding. These statements may form the basis of formal conformance testing and certification or informal assertions. This document makes no statement about the formal processes or method of certification; it only deals with criteria.
The terms defined in 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".
Whereas the Information Model used plain formatted English terms for element names, since the language of the specification is English, the XML Binding uses tokens for element names. These follow the lower camel case convention and 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 this document; translation of XML element names is not permitted. This restriction will ensure machine-level interoperability of data. See Table 2.2 - Binding names for Information Model elements in the XML Binding document.
Annotations and comment strings in the official IMS VDEX 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 IMS1. 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.
Conformance statements are divided into sections for the Information Model and for the XML Binding. At the current point in time, there is no other binding published by IMS but it is conceptually cleaner to identify statements that are binding independent.
- Data types must conform to the specifications of the Information Model
- Value spaces must conform to the specifications of the Information Model. This includes but is not necessarily limited to the requirements that:
- Data element multiplicities must be within the limits defined for the profile type in use ("lax", "thesaurus", "flatTokenTerms", "hierarchicalTokenTerms" or "glossaryOrDictionary").
- The number of characters in elements of type "string" may exceed the "SPM" defined in the Information Model.
- Term relationships for monolingual thesauri should use the value domain identifiers and permitted term values defined in the Information Model specification.
- Term relationships for multilingual thesauri should use the value domain identifiers and permitted term values defined in the Information Model specification unless the thesaurus contains only exact equivalences.
- Extensions to the Information Model may be used provided that in all other respects the requirements of this document are met.
- Langstring-containing elements must not contain more than one langstring where the same language is identified (including the case of no language being identified).
- The language property of a langstring must conform to the requirements of RFC1766.
- Processors must handle data that is valid in respect to the mandatory requirements of section 2.1.1.
- A conformant receiver must support at least one of the profile types ("lax", "thesaurus", "flatTokenTerms", "hierarchicalTokenTerms" or "glossaryOrDictionary")2.
- Processors must handle at least the number of characters in elements of type "string" as defined under "SPM" in the Information Model.
- Processors should not require the presence of extensions.
- A processor may reject data where an optional element has not been used3 only if the data-exchanging parties both agree to an additional set of restrictions (an "application profile").
- Arbitrary content of the <metadata> element must be accepted (i.e., must not cause errors or process abortion).
- Contents of the meta-data element may be ignored.
- A conformant creator must create valid data as defined in section 2.1.1.
- A conformant creator must support at least one of the profile types ("lax", "thesaurus", "flatTokenTerms", "hierarchicalTokenTerms" or "glossaryOrDictionary")4.
- The Vocabulary Identifier element must be controlled as described in the VDEX Information Model.
- Data may be included within the <metadata> element.
- Term Identifiers must be unique.
- Relationship referential integrity must be rigorously assured. This applies strictly only to terms referenced within the same vocabulary.
- The most restrictive profile type should be declared that is sufficient to permit the elements required for the type of vocabulary being created.
- A conformant XML 1.0 VDEX instance or processor must conform to the requirements of section 2.1, VDEX Information Model.
- A conformant VDEX XML instance must conform to the W3C XML 1.0 Specification (http://www.w3.org/TR/1998/REC-xml-19980210).
- A conformant VDEX XML instance must declare the namespace "http://www.imsglobal.org/xsd/imsvdex_v1p0".
- A conformant VDEX XML instance should associate the namespace with a control document such that it can be validated.
- A conformant VDEX XML instance must be valid according to the control document located on the IMS website under http://www.imsglobal.org/xsd/.
- A conformant VDEX XML instance should be encoded using UTF-8.
- Any extensions are expressed as described in IMS Vocabulary Definition Exchange Binding Guide Version 1.0.5
- If meta-data is present then it must be included as described in IMS Vocabulary Definition Exchange Binding Guide Version 1.0.
- Processors must handle data that is valid according to the mandatory requirements of sections 2.2.1 and 2.2.2
- Processors may reject data that does not conform to the mandatory requirements of sections 2.2.1 and 2.2.2 and should emit a warning if invalid data is processed.
- Processors must handle UTF-8 encoded data
- Processors may handle data encoded in schemes other than UTF-8
- Processors must create data that is valid according to the mandatory requirements of sections 2.2.1 and 2.2.2
- The transmitted XML instance should be lexically identical
- 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)
- Conformance summary - this is a summary that shows, in colloquial terms, the capabilities of a particular implementation with respect to the IMS VDEX Specification;
- Interoperability statement - this is a detailed technical checklist that identifies all of the feature capabilities of the implementation in terms of the IMS VDEX Conformance Requirements Specification (this document).
- 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 VDEX being required);
- Where extensions have a functional role and what that role is.
|Title||IMS Vocabulary Definition Exchange Conformance Requirements|
|Version Date||23 February 2004|
|Summary||This document describes the Conformance Statements applicable to the Vocabulary Definition Exchange Specification|
|Revision Information||February 2004|
|Purpose||Defines the VDEX Conformance|
|To register any comments about the VDEX specification, please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=18|
|Adam Cooper||FD Learning|
|Brendon Towle||Thomson NETg|
|Version No.||Release Date||Comments|
|Public Draft 1.0||4 August 2003||The first draft of the VDEX Conformance specification.|
|Final 1.0||23 February 2004||Made minor editorial changes, and added a new section about localization.|
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Vocabulary Definition Exchange 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 Vocabulary Definition Exchange Conformance Requirements Revision: 23 February 2004