IMS Logo

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:

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:

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



Table of Contents

1. Introduction
     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.1 Thesaurus
     3.2 Flat Token List
     3.3 Hierarchical Tokens (Taxonomy)
     3.4 Glossary or Dictionary

4. Extensibility
     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

Revision History


1. Introduction

This section is normative.

1.1 Namespace and Status of the Binding

This document describes an XML binding of the IMS Vocabulary Definition Exchange version 1.0 using XML version 1.0, hereafter termed "VDEX XML binding".

This binding is identified by the namespace

1.2 W3C XML Schema 1.0 Control Document

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.

The W3C XML Schema 1.0 Control Document released with this binding has been created according to the following principles.

  1. All elements names are unique in the namespace; the same element name is not used with different meaning in different places.
  2. No other namespace is explicitly referenced; this avoids 'tie-in' to specifications that are evolving.
  3. Elements are derived from an appropriately defined complex or simple type
  4. Replacement of elements by derivatives is blocked (see section 4.4).
  5. 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 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=""
   xsi:schemaLocation=" imsvdex_v1p0 imsvdex_v1p0.xsd"

1.2.1 Ordering of Elements

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.

1.2.2 Repeated Elements

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:

   <langstring language="en">Title</langstring >
   <langstring language="es">Título</langstring >

identifies two equivalent titles with no precedence.

1.2.3 Location of IMS VDEX Binding Instances

The .xsd files1 found at 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, 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.

For example, the non-normative examples of XML Schema files named for various binding instances of IMS VDEX v1.0 would be held at this location -- .

1.2.4 XML Schema File Naming Convention

Conformant with IMS file naming conventions, an IMS VDEX XML Schema binding instance shall be named according to this syntactical model: imsvdex_vmpn[pr[ps]][pd].xsd , where

  • "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.

Non-normative examples of XML Schema file names for IMS VDEX:

  • "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.

1.2.5 Notes for How IMS Will Version Binding Instances

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.

A change to binding structures without a related change to a specification version shall result in an increment of the major or minor revision level component of a binding's file name.

Changes to binding structures without a related change in a specification shall result in an increment of the major revision level.

Changes to structure names or values without changes in structures themselves or the meaning associated with a value shall result in an increment of the minor revision level.

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 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.

Each XSD file internally states its version, for example:

<xs:schema targetNamespace="" xmlns:xs="" xmlns="" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">

1.3 Valid Character Sets

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.

1.4 IMS Vocabulary Definition Exchange Specification Components

This document is the IMS Vocabulary Definition Exchange Specification version 1.0 XML Binding. As such, it forms one of a set that comprise the specification, each with distinct scope:

1.4.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., whether mandatory or optional).

1.4.2 XML Binding Guide (this document)

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.

1.4.3 Best Practices and Implementation Guide

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.

1.4.4 Conformance Requirements

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.

2. Narrative Description of XML Schema Binding

This section is normative.

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.

Key to graphical elements:
Rectangle with square corners = element
Rectangle with rounded corners, enclosed in red outline area = attribute
Bold name in upper half of rectangle: element/attribute name
Regular weight name in lower half of rectangle: type name

Circled Multiplicity indicator to left of element, attribute, or group:
? = 0..1
* = 0..n
+ = 1..n
D = 0..1, with default value if absent (attributes only)
(no indicator) = 1

Branching lines (red in color copy)
(grouping model)
Square bracket = "Sequence"
Angle bracket = "Choice" (not used in this specification)

Shows locations where elements from other namespaces may be included in a VDEX instance. These should declare a suitable XML namespace.

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.

XML Binding Schematic Diagram


Figure 2.1- XML Binding Schematic Diagram.


Table 2.1 - Binding names for Information Model elements.

Information Model Name Content Type for Text-containing elt/attr XML Binding Element or attribute Name
Order Significant boolean @orderSignificant
Profile Type string (enumerated) @profileType
Vocabulary Name - vocabName
Vocabulary Identifier anyURI vocabIdentifier
Registration Status boolean @isRegistered
Default Language language language
Term - term
Identifier anyURI termIdentifier
Valid Index Boolean validIndex
Caption - caption
Description - description
Media Descriptor - mediaDescriptor
Media Location anyURI mediaLocator
Interpretation Note - interpreatationNote
Relationship - relationship
Identifier anyURI identifier
Source Term/Term Identifier anyURI sourceTerm
Source Term/Vocabulary Identifier anyURI sourceTerm/@vocabularyIdentifier
Target Term/Term Identifier anyURI targetTerm
Target Term/Vocabulary Identifier anyURI targetTerm/@vocabularyIdentifier
Relationship type - relationshipType
Source of relationship type anyURI @source
Value of relationship type string {text content of relationshipType}
Metadata - metadata
Language string - langstring
Language of langstring language language
Content of langstring string {text content of langstring}
Note: "@" denotes an attribute in the binding


Table 2.2 - Commentary for Element binding.

Element Note Examples
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=""
xsi:schemaLocation=" imsvdex_v1p0.xsd xml.xsd"
vocabName There must be at least one langstring
   <langstring language="en">UK Driving Offence Codes</langstring>
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
   <langstring language="es">Frenar en seco</langstring>
   <langstring language="en">Braking Hard</langstring>
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"
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 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.

2.1 Identifier Element Content

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:


shows a simple example of an escaped URI that has an equivalent text content of " Driving"

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.

2.1.1 Identifier Uniqueness and Relationship Constraint

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.

2.2 Use of Profile Types

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:

  1. 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.
  2. 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.

All XML instances, whether profiled instances or not must conform to the VDEX binding described in the previous sections of this document and so are expected to be valid against the generic XSD.

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.


Table 2.3 - The relation of profile types to the XSD files.

Profile Type Name of XSD
lax (the generic non-type) imsvdex_v1p0.xsd
(these are identical)
thesaurus imsvdex_v1p0_thesaurus.xsd
hierarchicalTokenTerms imsvdex_v1p0_hierarchical.xsd
glossaryOrDictionary imsvdex_v1p0_glossary.xsd
flatTokenTerms imsvdex_v1p0_flat.xsd

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.

2.3 Including Meta-Data

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.

3. Restricted Bindings for Profile Types

This section is normative.

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.

3.1 Thesaurus

XML binding schematic diagram,


Figure 3.1 - XML Binding schematic diagram, "thesaurus".

3.2 Flat Token List

XML binding schematic diagram,


Figure 3.2 - XML Binding schematic diagram, "flatTokenTerms".

3.3 Hierarchical Tokens (Taxonomy)

XML binding schematic diagram,


Figure 3.3 - XML Binding schematic diagram, "hierarchicalTokenTerms".

3.4 Glossary or Dictionary

XML binding schematic diagram,


Figure 3.4 - XML Binding schematic diagram, "glossaryOrDictionary".

4. Extensibility

This section is normative.

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.

This section is not wholly part of the binding; the namespace extension mechanism described below includes conditions that arise from the use and style of use of W3C XML Schema 1.0.

4.1 Extensions with DTDs

No Document Type Description is released with this specification and their use is not recommended; W3C XML Schema 1.0 should be used with its namespace-driven extension mechanism described below.

4.2 Namespaced Element Extension Mechanism

Extension by inclusion of additional elements may be achieved at the following locations, identified in the various XML Binding diagrams by "#wildCard":

  • <vdex>
  • <term>
  • <mediaDescriptor>
  • <relationship>
  • <metadata>

Subject to the conditions:

  • 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 in the current case). The null namespace (xmlns="") may be used for cases where there is no specified namespace.

The namespace of the extension may employ either "block" or "prefix" mechanisms. For example in the equivalent fragments:

      <imsmd general>
            <imsmd:langstring language="en">Example</imsmd:langstring>
      </imsmd general>

(where the prefix imsmd has previously been declared by xmlns:imsmd="")


   <lom xmlns="">
            <langstring language="en">Example</langstring>

4.3 Namespaced Attribute Extension Mechanism

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.

4.4 Restrictions and Conditions

All other mechanisms for extension to binding instances other than described above are prohibited. This means:

  • 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.

The IMS VDEX XML Schema Definition file enforces some of these restrictions by defining block="#all" on the element definitions.

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.

Appendix A - Additional Resources

IEEE 1484-12.1-2002: Standard for Learning Object Metadata (LOM)

The IEEE 1484-12.1-2002: Standard for Learning Object Metadata can be obtained from IEEE, IMS Control Documents

The W3C XML Schema 1.0 Control Document, imsrdceo_rootv1p0.xsd, is located at:

IMS PLID Handbook

IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook version 1.0, [IMSPLID]

ISO/IEC 10646

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,

RFC 1766, Tags for the Identification of Languages,
(this is now made obsolete by RFC 3066)

RFC 2044, UTF-8, a transformation format of Unicode and ISO 10646,

RFC 2141, URN Syntax,

RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax,

RFC 3066, Tags for the Identification of Languages, Unicode

The Unicode Consortium. The ff Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996. XML

XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001:

XML Schema Part 1: Structures, W3C Recommendation, 2 May 2001:

XML Schema Part 2: Datatypes, W3C Recommendation, 2 May 2001:

XML Version 1.0 Specification of the W3C:

XML Namespace Recommendation of W3C:

About This Document

Title IMS Vocabulary Definition Exchange XML Binding
Editor Adam Cooper
Version 1.0
Version Date 23 February 2004
Status Final Specification
Summary This document describes the Vocabulary Definition Exchange XML Binding.
Revision Information February 2004
Purpose Defines the VDEX XML Binding.
Document Location

To register any comments about the VDEX specification, please visit:

List of Contributors

The following individuals contributed to the development of this document:

Name Organization
Adam Cooper FD Learning
Mark Norton IMS Global Learning Consortium, Inc.
Brendon Towle Thomson NETg
Claude Ostyn Click2learn, Inc.
Lorna Campbell CETIS
Michael Pelikan Penn State University
Brendon Towle Thomson NETg

Revision History

Version No. Release Date Comments
Public Draft 1.0 4 August 2003 The first public draft of the VDEX Specification.
Final 1.0 23 February 2004 Made minor editorial changes, as well as:
a) Moved the section about localization to the Conformance spec
b) Update the diagrams
c) Updated the information model element names
d) Added information about 'relationship' in Table 2.2


ISO 1, 2

meta-data 1

namespace 1, 2, 3, 4, 5, 6, 7, 8

restrictive 1, 2, 3

schema 1

term 1, 2, 3, 4, 5, 6

unicode 1

XML 1, 2, 3

There are multiple XSD files released with this specification, as described in section 3.
ALL conditions and requirements of the Information Model apply to the binding. These notes describe particular facets of the XML binding or additional restrictions on the element content imposed by the binding.




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

Please refer to Document Name:
IMS Vocabulary Definition Exchange XML Binding Revision: 23 February 2004