1EdTech Vocabulary Definition Exchange XML Binding Version 1.0 Final Specification

Copyright © 2004 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech 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.

1EdTech 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 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2004 1EdTech 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 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech 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 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 1EdTech VDEX Binding Instances
           1.2.4 XML Schema File Naming Convention
           1.2.5 Notes for How 1EdTech Will Version Binding Instances
     1.3 Valid Character Sets
     1.4 1EdTech 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

Index

1. Introduction

This section is normative.

1.1 Namespace and Status of the Binding

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

This binding is identified by the namespace http://www.imsglobal.org/xsd/imsvdex_v1p0.

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 1EdTech 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 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 1EdTech 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">

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:

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

identifies two equivalent titles with no precedence.

1.2.3 Location of 1EdTech VDEX Binding Instances

The .xsd files1 found at http://www.imsglobal.org/xsd/imsvdex/ shall be the current XML Schema binding instances of the 1EdTech 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 1EdTech 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.

For example, the non-normative examples of XML Schema files named for various binding instances of 1EdTech VDEX v1.0 would be held at this location -- http://www.imsglobal.org/xsd/imsvdex/v1p0/ .

1.2.4 XML Schema File Naming Convention

Conformant with 1EdTech file naming conventions, an 1EdTech 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 1EdTech Vocabulary Definition Exchange specification,
• "vm" is a major version of the 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech VDEX:

• "imsvdex _v1p0.xsd" is a binding tied to 1EdTech 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 1EdTech Will Version Binding Instances

A binding version of the 1EdTech 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 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.

Each XSD file internally states its version, for example:

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

1.3 Valid Character Sets

An 1EdTech 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 1EdTech Vocabulary Definition Exchange Specification Components

This document is the 1EdTech 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 1EdTech 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 1EdTech 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 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>
   <langstring language="en">UK Driving Offence Codes</langstring>
</vocabName>

<vocabIdentifier>URN:1EdTech-PLIRID-V0::6abd6e8f675fb87108db8cd0</vocabIdentifier>
<vocabIdentifier>http://www.imsglobal.org/vocabularies/UK%20Driving</vocabIdentifier>

<termIdentifier>exact</termIdentifier>

<caption>
   <langstring language="es">Frenar en seco</langstring>
   <langstring language="en">Braking Hard</langstring>
</caption>

<relationship>
<sourceTerm>sailboat</sourceTerm>
<targetTerm>boat</targetTerm>
<relationshipType
source="http://www.imsglobal.org/vocabularies/iso2788_relations.xml">
BT</relationshipType>
</relationship>

<langstring language="en">Braking Hard</langstring>

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:

<vocabIdentifier>http://www.imsglobal.org/vocabularies/UK%20Driving</vocabIdentifier>

shows a simple example of an escaped URI that has an equivalent text content of "http://www.imsglobal.org/vocabularies/UK 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 1EdTech 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.

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

3.2 Flat Token List

3.3 Hierarchical Tokens (Taxonomy)

3.4 Glossary or Dictionary

4. Extensibility

This section is normative.

Some applications of the 1EdTech 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 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.

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

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

(where the prefix imsmd has previously been declared by xmlns:imsmd="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1")

and:

<metadata>
   <lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1">
      <general>
         <title>
            <langstring language="en">Example</langstring>
         </title>
      </general>
   </lom>
</metadata>

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 1EdTech VDEX XML Schema Definition File (XSD) shall not be modified;
• Elements within the 1EdTech VDEX namespace shall not be modified;
• All elements in an instance document that are defined to be within the 1EdTech 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 1EdTech 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 1EdTech VDEX namespace shall not be extended or restricted within the 1EdTech VDEX namespace.

The 1EdTech 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 1EdTech VDEX namespace. The XML Schema Definition file enforces this restriction by defining namespace="##other" on all wildcard elements and attributes defined within the 1EdTech VDEX namespace.

As a potential aid to implementers, the types defined in the 1EdTech 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 1EdTech 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, http://www.ieee.org 1EdTech Control Documents

The W3C XML Schema 1.0 Control Document, imsrdceo_rootv1p0.xsd, is located at: http://www.imsglobal.org/xsd/imsrdceo_rootv1p0.xsd

1EdTech PLID Handbook

1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook version 1.0, [IMSPLID]
http://www.imsglobal.org/implementationhandbook/imsrid_handv1p0.html

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

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

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History

Index

I
ISO 1, 2

M
meta-data 1

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

R
restrictive 1, 2, 3

S
schema 1

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

U
unicode 1
URI 1

X
XML 1, 2, 3