IMS Vocabulary Definition Exchange XML Binding
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 XML Binding
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 Namespace and Status of the Binding
1.2 W3C XML Schema 1.0 Control Document
1.2.1 Ordering of Elements
1.2.2 Repeated Elements
1.2.3 Location of IMS VDEX Binding Instances
1.2.4 XML Schema File Naming Convention
1.2.5 Notes for How IMS Will Version Binding Instances
1.3 Valid Character Sets
1.4 IMS Vocabulary Definition Exchange Specification Components
1.4.1 Information Model
1.4.2 XML Binding Guide (this document)
1.4.3 Best Practices and Implementation Guide
1.4.4 Conformance Requirements
2. Narrative Description of XML Schema Binding
2.1 Identifier Element Content
2.1.1 Identifier Uniqueness and Relationship Constraint
2.2 Use of Profile Types
2.3 Including Meta-Data
3. Restricted Bindings for Profile Types
3.2 Flat Token List
3.3 Hierarchical Tokens (Taxonomy)
3.4 Glossary or Dictionary
4.1 Extensions with DTDs
4.2 Namespaced Element Extension Mechanism
4.3 Namespaced Attribute Extension Mechanism
4.4 Restrictions and Conditions
Appendix A - Additional Resources
About This Document
List of Contributors
A schema is a formal specification of element names that indicates which elements are allowed in an XML instance, and in which combinations. The VDEX Specification is being released with a control document using W3C XML Schema 1.0 (i.e., an XSD file) and not with a document type description (DTD). This reflects the development of XML specifications and the almost-universal adoption of W3C XML Schema 1.0 due to its greater flexibility and precision.
This specification is accompanied by a file using W3C XML Schema 1.0 (imsvdex_v1p0.xsd) as a non-normative reference that describes the binding rather than being the binding. Some XML editors may make use of these schemas to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of the schemas to validate their XML instances and/or to define extensions to the IMS VDEX XML Binding. Implementers of this specification should be aware that validating parsers differ in conformance to and implementation of W3C XML Schema 1.0 and the validity of a given XML instance document is rarely proven or dis-proven by the behavior of a given validating parser. Details of the construction of schemas are outside the scope of this document.
- All elements names are unique in the namespace; the same element name is not used with different meaning in different places.
- No other namespace is explicitly referenced; this avoids 'tie-in' to specifications that are evolving.
- Elements are derived from an appropriately defined complex or simple type
- Replacement of elements by derivatives is blocked (see section 4.4).
- Element and attribute names and enumeration values use the lower camelCase convention (e.g., "namingConvention")
The W3C XML Schema 1.0 Control Document is has been tested to valid according to the namespace http://www.w3.org/2001/XMLSchema and to be usable for xml instance validation using:
- Microsoft XML Parser version 4
- Microsoft .Net Framework 1.1
- XML Spy version 4.4
- XML Authority 2.2 (excluding instance validation)
- Xerces for Java 2.4.0
The following excerpt shows a suitable header for a VDEX XML instance. Note that the xsi:schemaLocation attribute is associating the namespace with a copy of the control document local to the VDEX instance rather than a master copies on the IMS Web server. This is probably good practice in most cases, especially if XML is to be processed disconnected from the Internet or if the overhead/delay of an HTTP request is undesirable. If XML is exchanged with local XSD file references then it is advisable to include the XSD files in the exchange process.
<?xml version="1.0" encoding="utf-8"?> <vdex profileType="lax" xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" xsi:schemaLocation="http://www.imsglobal.org/ imsvdex_v1p0 imsvdex_v1p0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Where XML elements are containers for lists of other elements, it is often practical to define a sequence for elements in the list when using W3C XML Schema 1.0. The ordering of these elements must be followed for XML document validity. The Information Model, however, does not define an element order. The VDEX Project Team considered approaches to W3C XML Schema 1.0 that would allow the binding to be expressed without fixed element ordering but tests with several widely used XML parsers suggested that there was inadequate support for the constructs required to achieve this aim. Consequently, on grounds of pragmatism, it was decided to produce a binding where the order was fixed.
To take account of the possibility of future relaxation of the above restriction, arising from developments of XML parsers or the potential adoption of less restrictive XML schema languages, implementers should be cautious. Cautiousness may entail, for example:
- not assuming any element order when reading VDEX XML instances but using a technology such as Xpath;
- obeying the element ordering described in the following sections when writing VDEX XML instances.
Repeating the containing element at its specific location in the XML structure creates an unordered list of contents by default. The order of the repetitions has no significance except where information is provided through the "orderSignificant" property of terms or the entire vocabulary. See the VDEX Information Model. All other repeatable elements in VDEX XML Binding are to be interpreted as unordered. For example:
<title> <langstring language="en">Title</langstring > <langstring language="es">Título</langstring > </title>
The .xsd files1 found at http://www.imsglobal.org/xsd/imsvdex/ shall be the current XML Schema binding instances of the IMS VDEX Information Model normative elements and values. Warning: These files will change when a version increment of VDEX is made.
Versioned instances of each binding for IMS VDEX, including all major or minor release instances of that version's binding, can be found at http://www.imsglobal.org/xsd/imsvdex/vmpn/, where "vmpn" is a folder named for a versioned instance of the specification. This applies to the most recent version as well as any historical versions. Persistent copies of the public draft will be available at this location but named, imsvdex_v1p0pd.xsd etc.
- "imsvdex_" signifies that the file pertains to the IMS Vocabulary Definition Exchange specification,
- "vm" is a major version of the IMS VDEX specification defined by a binding instance, where "m" is the major version number, and is always followed by
- "pn", which signifies a minor version of the IMS VDEX Specification defined by a binding instance, where "n" is minor version number, and where
- [pr[ps]] is an optional set of major release and minor release numbers (as indicated by the brackets which are not part of the file name), depending on changes to schema instances themselves that are not driven by a change to a normative instance of the IMS VDEX specification, with
- "pr" representing a major release component without an additional minor release part, where "r" is the major release number, and with
- "ps" representing a minor release component modifying an major release component, where "s" is the minor release number.
- "pd" identifies a Public Draft Specification XML schema binding instance.
- "imsvdex _v1p0.xsd" is a binding tied to IMS VDEX v1.0,
- "imsvdex _v1p0p1.xsd" is a 'major' revision of the imsvdex _v1p0.xsd binding instance,
- "imsvdex _v1p0p1p1.xsd" is 'minor' revision of imsvdex _v1p0p1.xsd binding instance.
A binding version of the IMS VDEX specification shall always reflect the current version number of the specification, whether or not binding structures change across specification instances. That is, the file name of the current binding instance shall share the same major and minor version number of the specification.
All versioning and revisioning shall be reflected in a binding's file name and complete version information. This new binding shall become the current binding found at http://www.imsglobal.org/xsd/imsvdex. The obsolete binding shall be moved to its place within the imsvdex file path structure based on the value of its version level component, excluding the revision level component.
<xs:schema targetNamespace="http://www.imsglobal.org/xsd/imsvdex_v1p0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">
An IMS VDEX instance should use the UTF-8 encoding, as defined in RFC 2044, of the character sets as defined in ISO 10646. Alternative encodings are possible but may restrict interoperability. Numeric entity references are not recommended.
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 or assertion; it only deals with criteria.
This section of the specification uses a series of graph segments, accompanied by simple narrative, to describe the XML format of the XSD binding for the Vocabulary Definition Exchange model. XSD documents that implement this abstract format are referenced as non-normative parts of this specification. Graph fragments are used in preference to full textual descriptions to reflect the familiarity and preference of consumers of IMS specifications with this representation, for clarity and conciseness.
It is often necessary for bindings to create structuring entities with names that are not present in an information or data model that is being expressed in XML Schema. These special structuring enable the grouping and use of elements as defined in a data model.
Figure 2.1 shows the diagram for the XML Binding. Table 2.1 should be consulted to relate the XML Binding names to the Information Model and Table 2.2 provides simple examples and any special caveats applicable to the binding2 of the element or its content attributes or elements.
|vdex|| This element should contain namespace information.
The profileType attribute is an enumerated string; its value must be from the list of permitted values given in the VDEX Information Model.
<vdex profileType="lax" xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" xsi:schemaLocation="http://www.imsglobal.org/imsvdex_v1p0 imsvdex_v1p0.xsd http://www.w3.org/XML/1998/namespace xml.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|vocabName||There must be at least one langstring||
<vocabName> <langstring language="en">UK Driving Offence Codes</langstring> </vocabName>
|vocabIdentifier||See section 2.1.1 for restrictions on lexical content.||
|term||At least one term must be present||
|termIdentifier|| See section 2.1.1 for restrictions on lexical content.
The value of termIdentifier must be unique in the VDEX instance.
|caption||There must be at least one langstring||
<caption> <langstring language="es">Frenar en seco</langstring> <langstring language="en">Braking Hard</langstring> </caption>
|description||There must be at least one langstring||
|mediaDescriptor||xml:base should not be used; the mediaLocator should be sufficient on its own to locate the resource. There must be a mediaLocator if mediaDescriptor is used.||
|relationship|| The relationship type is expressed as a value in a domain (called "source"). The source is bound as "xs:anyURI". Section 2.1.1 describes limitations this imposes. The absence of vocabulary identifier information for the source and target terms is taken to mean that the terms appear in the same vocabulary as the relationship is defined in.
NB: this does not mean that the terms must appear in the same XML instance since it may be a fragment"
<relationship> <sourceTerm>sailboat</sourceTerm> <targetTerm>boat</targetTerm> <relationshipType source="http://www.imsglobal.org/vocabularies/iso2788_relations.xml"> BT</relationshipType> </relationship>
|metadata||This element contains no defined content. See section 2.3.||
|langstring||The language is not expressed using xml:lang as in some other IMS specifications1.||
<langstring language="en">Braking Hard</langstring>
The use of the xml: prefix and the referencing of attributes in the namespace http://www.w3.org/XML/1998/namespace has been the cause of serious interoperability problems arising from differing rules being applied by different XML parsers. W3C XML Schema 1.0 provides a data type for language codes so that it is possible to apply the same restriction as xml:lang directly within the XSD.
The XML schema data type for identifiers is "anyURI". Characters not allowed in a URI or a URI reference must be escaped as defined in RFC 2396 (as amended by RFC 2732) when creating the XML instance and unescaped when it is processed. If it is necessary to escape characters not defined in RFC 2396, the transformation format defined in RFC 2044 must be used. Where escaping in the form "%xx" may be used but is not required when following these RFCs, it should be used in VDEX instances. The fragment:
Note that the requirement that element content is lexically a URI does not require it to be a URI nor should it necessarily require that data entry by users uses the URI-encoded form. In particular, term identifiers may often be simple short text strings. The best practice guide elaborates on practical approaches to choosing and using identifiers.
The term identifier is required to be unique. The use of the W3C XML Schema 1.0 identity constraint mechanism, xs:unique, was considered for VDEX but this version of VDEX does not use this mechanism because several widely used XML parsers do not currently provide support. The premature use of these in the binding would probably lead to practices that harmed interoperability. Implementers should be aware, however, that future versions of VDEX are highly likely to use such validity constraints as part of the XSD and they are strongly advised to heed the requirements of the Information Model and current binding in relation to uniqueness. An XML instance that does not meet the requirements is not conformant, no matter whether it passes parser validation or not.
The Information Model described several profile types that allow the more general VDEX model to be restricted. This section describes how a set of XSD documents should be used to control XML instances when profile types are used. NB: All instances use the same XML namespace no matter which profile type is used and no matter which profile XSD is used.
If a profile type other than the generic type of "lax" (hereafter these are called "profiled instance[s]") is used then the matching restrictive XSD should be used if practicable. There may be cases when the reference to XSDs is modified:
- Applications receiving a profiled instance where the generic XSD is located by the instance may replace the reference by one which locates the XSD that matches the profile declared in the instance.
- Conversely, applications receiving a profiled instance where a profile-describing XSD is located may change this to a reference to the generic XSD.
Implementations must ensure that the first type of replacement will not cause the instance to fail a validity check: that is, if a profile type is declared in the XML instance then the document must conform to that profile. The XSD documents provided by IMS ensure that the second type of replacement will not lead to validation errors.
Applications that only process particular profile types should only use the value of the profileType attribute to choose whether to accept or reject an XML instance. Furthermore, they must be able to handle either a profiled or generic XSD (and must not use the identity of the XSD to determine the profile type). Users of the profiled XSD files will notice that the profileType attribute is mandatory.
The XSD documents for non-lax profile types require the profileType attribute to be present in the instance and require that its value exactly matches the relevant profile type string. This means that such that a profile XSD may only be used with instances declaring a profile type; it is not sufficient for the vocabulary data to actually be of a particular profile.
Meta-data is included within the <metadata> element. No content is explicitly defined inside this element; it is a container for meta-data in arbitrary schema, although the VDEX Best Practices and Implementation Guide makes some comments on choice of schema. In technical terms, meta-data is included using the same mechanism as should be used to extend VDEX XML using XML Namespace. Section 4.2 discusses this mechanism and an example of meta-data appear in the Best Practices and Implementation Guide.
This section provides diagrams as in Section 1.4 that show how XML-bound data should be expressed when a profile type is used. These diagrams should make an unambiguous statement about the application of the restrictions described in the VDEX Information Model to the generic XML binding.
Some applications of the IMS VDEX may find the element set defined in the Information Model and XML Binding to be too restrictive to meet all of their needs. Extensibility was discussed in general terms in the VDEX Information Model; this section describes how it should be achieved in XML-bound instances.
- the extension elements must follow the elements defined in this specification.
- the extension elements contain a namespace declaration different from the containing element (i.e., not http://www.imsglobal.org/xsd/imsvdex_v1p0 in the current case). The null namespace (xmlns="") may be used for cases where there is no specified namespace.
<metadata> <imsmd:lom> <imsmd general> <imsmd:title> <imsmd:langstring language="en">Example</imsmd:langstring> </imsmd:title> </imsmd general> </imsmd:lom> </metadata>
<metadata> <lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1"> <general> <title> <langstring language="en">Example</langstring> </title> </general> </lom> </metadata>
A similar mechanism to 4.2, Namespaced Element Extension Mechanism, may be used to append attributes to any element. This facility is again subject to the requirement that the namespace of the attribute should differ from the parent element.
Attribute extension of elements may be used, for example, to qualify a nuance of interpretation appropriate to a specific application but permit systems that do not understand the nuance to process the same data with its broader sense.
- The IMS VDEX XML Schema Definition File (XSD) shall not be modified;
- Elements within the IMS VDEX namespace shall not be modified;
- All elements in an instance document that are defined to be within the IMS VDEX namespace shall conform exactly to the definition of that element provided in this binding description document;
- Elements in another namespace shall not be substituted for elements in the IMS VDEX namespace (via the XML Schema substitution group mechanism, for example, or via any other mechanism);
- The enumerations defined for elements and attributes within the IMS VDEX namespace shall not be extended or restricted within the IMS VDEX namespace.
All extensions shall be in a namespace other than the IMS VDEX namespace. The XML Schema Definition file enforces this restriction by defining namespace="##other" on all wildcard elements and attributes defined within the IMS VDEX namespace.
As a potential aid to implementers, the types defined in the IMS VDEX XML Schema Definition file may be imported into other namespaces and arbitrary elements or types reused within those other namespaces. However, any such reuse shall be consistent with the restrictions defined in the IMS VDEX Specification document set, especially in relation to the permitted content models of the VDEX elements that are used.
The IEEE 1484-12.1-2002: Standard for Learning Object Metadata can be obtained from IEEE, http://www.ieee.org IMS Control Documents
IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook version 1.0, [IMSPLID]
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7). RFCs
RFC 1648, A URN namespace for IETF documents, http://www.ietf.org/rfc/rfc1648.txt
RFC 1766, Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc1766.txt
(this is now made obsolete by RFC 3066)
RFC 2044, UTF-8, a transformation format of Unicode and ISO 10646, http://www.ietf.org/rfc/rfc2044.txt
RFC 2141, URN Syntax, http://www.ietf.org/rfc/rfc2141.txt
RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, http://www.ietf.org/rfc/rfc2396.txt
RFC 3066, Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc3066.txt Unicode
XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001: http://www.w3.org/TR/xmlschema-0/
XML Schema Part 1: Structures, W3C Recommendation, 2 May 2001: http://www.w3.org/TR/xmlschema-1/
XML Schema Part 2: Datatypes, W3C Recommendation, 2 May 2001: http://www.w3.org/TR/xmlschema-2/
XML Version 1.0 Specification of the W3C: http://www.w3.org/TR/1998/REC-xml-19980210
XML Namespace Recommendation of W3C: http://www.w3.org/TR/1999/REC-xml-names-19990114
|Title||IMS Vocabulary Definition Exchange XML Binding|
|Version Date||23 February 2004|
|Summary||This document describes the Vocabulary Definition Exchange XML Binding.|
|Revision Information||February 2004|
|Purpose||Defines the VDEX XML Binding.|
| To register any comments about the VDEX specification, please visit:
|Adam Cooper||FD Learning|
|Mark Norton||IMS Global Learning Consortium, Inc.|
|Brendon Towle||Thomson NETg|
|Claude Ostyn||Click2learn, Inc.|
|Michael Pelikan||Penn State University|
|Brendon Towle||Thomson NETg|
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Vocabulary Definition Exchange XML Binding ("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 XML Binding Revision: 23 February 2004