IMS Logo

IMS Content Packaging XML Binding

Version 1.1.3 Final Specification

Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Content Packaging XML Binding
Revision: 12 June 2003

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 © 2003 IMS Global Learning Consortium. All Rights Reserved.

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

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

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

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


 

Table of Contents


1. Introduction
     1.1 Overview
     1.2 Scope and Context
     1.3 Structure of this Document
     1.4 Nomenclature
     1.5 References

2. XML Basics
     2.1 Elements
           2.1.1 Element Contents
           2.1.2 Element Attributes
           2.1.3 Element Names
     2.2 Document Type Definitions
     2.3 XML Schemas
     2.4 Valid Character Sets
     2.5 Special Handling Requirements
           2.5.1 XML Reserved Characters
           2.5.2 White Space Handling

3. Narrative Description of XML Binding
     3.1 <manifest> Elements
           3.1.1 <metadata>
           3.1.2 <organizations>
           3.1.3 <resources>
     3.2 <metadata> Elements
           3.2.1 <schema>
           3.2.2 <schemaversion>
           3.2.3 Meta-data
     3.3 <organizations> Elements
           3.3.1 <organization>
           3.3.2 <title>
           3.3.3 <item>
           3.3.4 <metadata>
     3.4 <resources> Elements
           3.4.1 <resource>
     3.5 Extensibility

4. Samples

Appendix A - Additional Resources

About This Document
     List of Contributors

Revision History

Index


1. Introduction

1.1 Overview

This document describes the XML binding for the IMS Content Packaging v1.1.3 specification. This document specifies the binding of the Content Packaging specification in the W3C XML 1.0 Specification.

There are some specific rules that have guided the creation of this XML binding document:

  • The XML binding will adhere to the XML 1.0 Specification of the W3C;
  • It must maintain the definitional structure of the specification;
  • It must permit extensions.
  • The latest agreed practice within IMS is that camel case is used for the element tags in XML. This has not been adopted in this maintenance release because this would have required all previously created content package manifests to be altered. Instances that conform to CPv1.1.2 are compatible with CPv1.1.3 (with the exception of changing the XSD control document assignment in the header of the instance file).

1.2 Scope and Context

This document is the IMS Content Packaging XML Binding v1.1.3 specification. As such it will be used as the basis for the production of the following v1.1.3 documents:

  • IMS Content Packaging XML XSDs;
  • IMS Content Packaging Best Practice Guide [CP, 03c].

This binding has been derived from the agreed IMS Content Packaging Information Model v1.1.3 [CP, 03b] and conforms to the XML 1.0 Specification [XML, 98] of the W3C. Version 1.1.3 is a maintenance release update to the version 1.1.2 specification and a description of the changes is given in the accompanying addendum documents [CP, 03a].

1.3 Structure of this Document

The structure of this document is:

 
2. XML Basics A brief description of the components within an XML schema;
3. Narrative Description of XML Binding The description of the elements and attributes used within the XML binding itself;
4. Samples Several samples of content packages;
Appendix A - Additional Resources References to other Content Packaging related resources.

1.4 Nomenclature

 
CDATA Character Data
CPI Content & Packaging Interchange
DTD Document Type Definition
PCDATA Parsed Character Data
W3C World Wide Web Consortium
XML Extensible Mark-up Language

1.5 References

 
[CP, 03a] IMS Content Packaging Summary of Changes Final Specification 1A, C.Smythe, Version 1.1.3, IMS, April 2003.
[CP, 03b] IMS Content Packaging Information Model, C.Smythe, T.Anderson, M.McKell, A.Cooper, W.Young and C.Moffatt, Version 1.1.3, IMS, June 2003.
[CP, 03c] IMS Content Packaging Best Practice Guide, C.Smythe, T.Anderson, M.McKell, A.Cooper, W.Young and C.Moffatt, Version 1.1.3, IMS, June 2003.
[ISO/IEC10646] 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).
[Unicode, 96] The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
[XML, 98] XML 1.0 Specification of the W3C: http://www.w3.org/TR/1998/REC-xml-19980210.
[XML, 99] XML Namespace Recommendation of W3C: http://www.w3.org/TR/1999/REC-xml-names-19990114.

 
XML Schema Recommendation of W3C: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/.

2. XML Basics

The Content Packaging data model can be defined as a hierarchy. Hierarchical models are convenient for representing data consisting of many elements and sub-elements. XML is perfectly suited for representing hierarchical models. An XML document is a hierarchy comprised of elements that have contents and attributes.

2.1 Elements

An element is a component of a document that has been identified in a way a computer can understand. Each element has a tag name. When a tag name is shown as "<TAGNAME>", with less-than and greater-than symbols before and after the tag name, it serves as the start-tag to mark the beginning of an element. When that same tag name has a forward slash "/" added, it serves as an end-tag such as "</TAGNAME>". An element may have contents between its start and end-tags, and may have one or more attributes. When an XML element has a start and end-tag (also called an opening and closing tag) with a common name, it is considered to be "well-formed" XML. The contents of an element are placed between the start and end-tags as shown below:

<TAGNAME>contents</TAGNAME>

2.1.1 Element Contents

An element may contain other elements, Parsed Character Data (PCDATA), Character Data (CDATA), or a mixture of PCDATA and elements. The allowable contents of an element are its content model. PCDATA really means any character string that does not contain elements. PCDATA is what the bulk of elements will use between their start and end-tags. CDATA is different in that it is a method for adding any character data that should not be processed. For example, you could add some JavaScript code instructions using a CDATA section. A CDATA section tells the parser not to look for any mark-up until after it locates the end of the CDATA section.

2.1.2 Element Attributes

An attribute provides additional information about an element. Attributes are a way of attaching characteristics or properties to the elements of a document. An element may have more than one attribute. Attributes are contained within the start tag of an element. Attributes are represented by an attribute name followed by an equal sign and the attribute value in quotation marks:

<timeframe> 
   <begin restrict="1"> 1999-07-23 </begin>
</timeframe>

In this example, the <timeframe> element contains another element: the <begin> element. The <begin> element has one attribute 'restrict', with the value "1". The value for the element <begin> is "1999-07-23". These two elements then make up a timeframe begin date.

2.1.3 Element Names

Each element has a unique name, referred to as the tag name. XML is case-sensitive in its processing of tag names. The IMS Content Packaging XML Binding adheres to the following tag name rules:

  • All tag names will conform to the rules for element naming as given within the XML 1.0 Specification.
  • Names beginning in XML in any case or mix of cases are not permitted.
  • The IMS binding will use only lowercase tag and element names.
  • Element names may not include words reserved by the XML specification. These include:
    DOCTYPE
    ELEMENT
    ATTLIST
    ENTITY
  • Tag names defined by the IMS binding may not be redefined.

2.2 Document Type Definitions

The tag name, content model, and attributes of elements are defined in a Document Type Definition (DTD) statement. This may exist as an external file or a block of text internal to an XML document. Internal DTDs are used to override elements defined in external DTD files, so an internal DTD should be used with care. The DTD defines the elements that may be used and may define the contents of the elements.

This specification defines a DTD (imscp_rootv1p1.dtd) as a non-normative reference. Some XML editors may make use of a DTD to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of DTDs to validate their XML documents to ensure their document is consistent with all of the element names and locations defined in the DTD. Details of the construction of DTDs are outside the scope of this document, but links to the XML 1.0 Specification are included in section 1.5 of this document.

2.3 XML Schemas

A schema is a formal specification of element names that indicates which elements are allowed in an XML document, and in which combinations. New schema languages, such as those defined in the XML-Schemas Working Group, provide the same baseline functionality as a DTD. However, because these schema languages are extensible, developers can augment them with additional information, such as data types, inheritance, and presentation rules. This makes these new schema languages far more powerful than DTDs. For more information about XML schemas, there is a link to the W3C XML Schema Recommendation in section 1.5.

This specification defines a W3C XML Schema as a non-normative reference. Some XML editors may make use of 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 schemas to validate their XML documents and/or to define extensions to the IMS Content Packaging Binding. Details of the construction of schemas are outside the scope of this document.

2.4 Valid Character Sets

A Content Packaging record must use UTF-8 or UTF-16 encoding of the character sets as defined in ISO 10646. See the XML Version 1.0 for more details on the specification of well-formed XML.

2.5 Special Handling Requirements

2.5.1 XML Reserved Characters

Some characters used in XML must be escaped when used outside of their XML-defined usage as found in section 2.4 of the XML 1.0 Specification. These characters are ampersand (&), less than (<), greater than (>), apostrophe ('), and the double-quote character (").

These characters may be represented using either numeric character references or the strings "&", "<", ">", "&apos;", and """.

Below is a more complete quote from the W3C XML standards:

Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.4 Character Data and Markup

"Text consists of intermingled character data and markup. Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, CDATA section delimiters, document type declarations, and processing instructions.

"All text that is not markup constitutes the character data of the document.

"The ampersand character (&) and the left angle bracket (<) may appear in their literal form only when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. They are also legal within the literal entity value of an internal entity declaration; see "4.3.2 Well-Formed Parsed Entities". If they are needed elsewhere, they must be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.

"In the content of elements, character data is any string of characters, which does not contain the start-delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".

"To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as "&apos;", and the double-quote character (") as """."

2.5.2 White Space Handling

Questions often arise as to whether Web-based data transmission tools might inadvertently strip off or transform some of the white space characters embedded in data transmitted between systems using XML. To eliminate concern about this issue, refer to the following quote from the W3C XML standards, which indicate that all white space must be preserved where it is part of the data.

Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.10 White Space Handling

"In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines, denoted by the non-terminal S in this specification) to set apart the mark-up for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.

"An XML processor must always pass all characters in a document that are not mark-up through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content.

"A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose only possible values are "default" and "preserve". For example:

"<!ATTLIST poem xml:space (default|preserve) 'preserve'>

"The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute."

3. Narrative Description of XML Binding

This specification defines the XML format using narrative. XML DTDs and XML Schemas that implement this abstract format are referenced as non-normative parts of this specification.

3.1 <manifest> Elements

Description. The first, top-level <manifest> element in the Manifest encloses all the reference data. Subsequent occurrences of the <manifest> elements inside the top-level <manifest> are used to compartmentalize files, meta-data, and organization structure for aggregation, disaggregation, and reuse. The best-practice use of the IMS Content Packaging specification will result in each "learning object" or "atomic unit of learning" being placed within its own <manifest> element.

<manifest> elements

 

Figure 3.1 - <manifest> elements.

Multiplicity. The top-level <manifest> occurs once and only once within the IMS Manifest file.

Attributes

  • identifier (required). An identifier, provided by an author or authoring tool, that is unique within the Manifest. Data type = string;
  • version (optional). Identifies the version of the Manifest. Is used to distinguish between manifests with the same identifier. Data type = string;
  • xml:base (optional). This provides a relative path offset for the content file(s). The usage of this element is defined in the XML Base Working Draft from the W3C. Data type = string.

Elements

  • <metadata>
  • <organizations>
  • <resources>
  • <manifest>

3.1.1 <metadata>

<metadata> elements

 

Figure 3.2 - <metadata> elements.

Multiplicity. Occurs zero or once within a <manifest> element.

Elements

  • <schema>
  • <schemaversion>
  • Meta-Data: Implementers are free to choose from any of the meta-data elements defined in the IMS Meta-Data specification or other meta-data standards.

Example

<metadata>
   <schema>IMS Content</schema>
   <schemaversion>1.1</schemaversion>
   <imsmd:record>
      <imsmd:general>
         <imsmd:title>
            <imsmd:langstring xml:lang="en-US">Simple Manifest</imsmd:langstring>
         </imsmd:title>
      </imsmd:general>
   </imsmd:record>
</metadata>

3.1.2 <organizations>

Description. Describes zero, one, or more structures or organizations for this package.

<organizations> elements

 

Figure 3.3 - <organizations> elements.

Multiplicity. Occurs zero, once, or more within a <manifest> element.

Attributes

  • default (required). Identifies the default organization to use. Data type = idref.

Elements

  • <organization>

Example

<organizations default="TOC1">
   <organization identifier="TOC1" structure="hierarchical">
      <title>default</title>
      <item identifier="ITEM1" identifierref="RESOURCE1" isvisible="true">
         <title>Lesson 1</title>
         <item identifier="ITEM2" identifierref="RESOURCE2" isvisible="true">
            <title>Introduction 1</title>
         </item>
         <item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
            <title>Content 1</title>
         </item>
         <item identifier="ITEM4" identifierref="RESOURCE4" isvisible="true">
            <title>Summary 1</title>
         </item>
      </item>
      <item identifier="ITEM5" identifierref="RESOURCE5" isvisible="false">
         <title>Lesson 2</title>
         <item identifier="ITEM6" identifierref="RESOURCE6" isvisible="false">
            <title>Introduction 2</title>
         </item>
         <item identifier="ITEM7" identifierref="RESOURCE7" isvisible="false">
            <title>Content 2</title>
         </item>
         <item identifier="ITEM8" identifierref="RESOURCE8" isvisible="false">
            <title>Summary 2</title>
         </item>
      </item>
      <item identifier="ITEM9" identifierref="RESOURCE9" isvisible="true">
         <title>Lesson 3</title>
         <item identifier="ITEM10" identifierref="RESOURCE10" isvisible="true" parameters="foo">
            <title>Introduction 3</title>
         </item>
         <item identifier="ITEM11" identifierref="RESOURCE11" isvisible="true">
            <title>Content 3</title>
         </item>
         <item identifier="ITEM12" identifierref="RESOURCE12" isvisible="true">
            <title>Summary 3</title>
         </item>
      </item>
   </organization>
</organizations>

3.1.3 <resources>

Description. This element identifies a collection of physical content files.

<resources> elements

 

Figure 3.4 - <resources> elements.

Multiplicity. Occurs once and only once within a <manifest> element.

Attributes

  • xml:base (optional). This provides a relative path offset for the content file(s). The usage of this element is defined in the XML Base Working Draft from the W3C. Data type = string.

Elements

  • <resource>

Example

<resources>
   <resource identifier="RESOURCE1" type="webcontent" href="lesson1.htm">
      <file href="lesson1.htm"/>
   </resource>
   <resource identifier="RESOURCE2" type="webcontent" href="intro1.htm">
      <file href="intro1.htm"/>
   </resource>
   <resource identifier="RESOURCE3" type="webcontent" href="content1.htm">
      <file href="content1.htm"/>
   </resource>
   <resource identifier="RESOURCE4" type="webcontent" href="summary1.htm">
      <file href="summary1.htm"/>
   </resource>
</resources>

3.2 <metadata> Elements

3.2.1 <schema>

Description. Describes the schema used (e.g., IMS Content). If no schema element is present, it is assumed to be "IMS Content". Data type = string.

Multiplicity. Occurs zero or once within <metadata>.

Example

<schema>IMS Content</schema>

3.2.2 <schemaversion>

Description. Describes version of the above schema (e.g., 1,0, 1.1). If no version is present, it is assumed to be "1.1". Data type = string.

Multiplicity. Occurs zero or once within <metadata>.

Example

<schemaversion>1.1</schemaversion>

3.2.3 Meta-data

Description. See the IMS Meta-Data specification for more detail on the meta-data that are available for describing and cataloguing content packages. The IMS Meta-Data v1.2.1 is the default specification but other specifications/standards are permitted.

Multiplicity. Defined in the relevant meta-data specification.

Example: In-line meta-data

<metadata>
   <imsmd:record>
      <imsmd:general>
         <imsmd:title>
            <imsmd:langstring xml:lang="en-US">Simple Manifest</imsmd:langstring>
         </imsmd:title>
      </imsmd:general>
   </imsmd:record>
</metadata>

3.3 <organizations> Elements

3.3.1 <organization>

Description. This element describes a particular, passive organization of the material.

Multiplicity. Occurs zero or more times within <organizations>.

Attributes

  • identifier (required). An identifier, provided by an author or authoring tool, that is unique within the Manifest. Data type = id.
  • structure (optional). Assumes a default value of "hierarchical", such as is common with a tree view or structural representation of data. Data type = string.

Elements

  • <title>
  • <item>
  • <metadata>

Example

<organization identifier="TOC1">
   <title>default</title>
   <item identifier="ITEM1" identifierref="RESOURCE1" isvisible="true">
      <title>Lesson 1</title>
   </item>
   <item identifier="ITEM2" identifierref="RESOURCE2" isvisible="true">
      <title>Introduction 1</title>
   </item>
</organization>

3.3.2 <title>

Description. This element describes the title of an <item>.

Multiplicity. Occurs zero or more times within <item>.

3.3.3 <item>

Description. This element describes a node within a structure.

Multiplicity. Occurs zero or more times within <organization> and zero or more times within <item>.

Attributes

  • identifier (required). An identifier that is unique within the Manifest. Data type = id.
  • identifierref (optional). A reference to a <resource> identifier (within the same package) or a (sub)Manifest that is used to resolve the ultimate location of the file. If no identifierref is supplied, it is assumed that there is no content associated with this entry in the organization. Data type = string.
  • isvisible (optional). Indicates whether or not this resource is displayed when the unit of instruction is rendered. If not present, value is assumed to be 'true'. Data type = boolean.
  • parameters (optional). Static parameters to be passed to the content file at launch time. Data type = string.

Elements

  • <title>
  • <item>
  • <metadata>

Example

<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
   <title>Content 1</title>
</item>

3.3.4 <metadata>

Description. This element contains meta-data that describes the resource. Implementers are free to choose from any of the meta-data elements defined in the IMS Meta-Data specification or to define their own meta-data schema.

Multiplicity. Occurs zero or once within <organization>.

Example

<organization identifier="TOC1">
   <metadata>
   <!-- schema and schemaversion not given as they apply at manifest level -->
      <imsmd:record>
         <imsmd:educational>
            <imsmd:interactivitylevel>1</imsmd:interactivitylevel>
         </imsmd:educational>
      </imsmd:record>
   </metadata>
</organization>

3.4 <resources> Elements

A collection of references to resources. There is no assumption of order or hierarchy. Resources can be described in-line or externally.

3.4.1 <resource>

Description. This element describes a specific content file.

Multiplicity. Occurs zero or more times within <resources>.

Attributes

  • identifier (required). An identifier, provided by the author or authoring tool, that is unique within the Manifest.
  • 'type ' (required). A string that identifies the type of variant resource. This specification defines the type "webcontent" plus reserved terms that are used to denote the packaging of content defined by other IMS specifications, including Learning Design.
  • xml:base (optional). This provides a relative path offset for the content file(s). The usage of this element is defined in the XML Base Working Draft from the W3C. Data type = string.
  • href (optional). A reference to the "entry point" of this resource. External fully-qualified URIs are also permitted.

Elements

  • <metadata>
  • <file>
  • <dependency>

Example: In-line resource

<resource identifier="RESOURCE2" type="webcontent" href="topics/index.htm">
   <file href="topics/index.htm"/>
   <file href="images/pic1.gif"/>
   <file href="images/pic2.gif"/>
</resource>

3.4.1.1 <metadata>

Description. This element contains meta-data that describes the resource. Implementers are free to choose from any of the meta-data elements defined in the IMS Meta-Data specification or to define their own meta-data schema.

Multiplicity. Occurs zero or once within <resource>.

3.4.1.2 <file>

Description. Identifies one or more local files that this resource is dependent on. This includes the resource being referenced in the href attribute of <resource>. If the resource references an absolute URL (using href), <file> element(s) are not required.

Multiplicity. Occurs zero or more times within <resource>.

Attributes

  • href (required). URL of the file.

Element

  • <metadata>

Example

<file href="topics/index.htm"/>

3.4.1.3 <dependency>

Description. This element identifies a single resource that can act as a container for multiple files that this resource depends upon.

Multiplicity. Occurs zero or more times within <resource>.

Attributes

  • identifierref (required). An identifier for other resources to reference.

Example

<resources>
   <resource identifier="R_A2" type="webcontent" href="sco1.html">
      <metadata/>
      <file href="sco1.html"/>
      <dependency indentiferref="R_A5"/>
   </resource>
   <resource identifier="R_A5" type="webcontent" href="pics/distress_sigs_add.jpg">
      <metadata/>
      <file href="pics/distress_sigs_add.jpg"/>
   </resource>
</resources>

3.5 Extensibility

The IMS Content Packaging XML Binding is extensible through the use of XML Namespaces and XML Schemas. It is expected that the extensibility mechanism will be used to describe additional types of meta-data, organizations, and resources. More information and examples of extensibility are contained in the IMS Content Packaging Best Practice Guide.

4. Samples

The samples referenced by the IMS Content Packaging specification are available for download at http://www.imsglobal.org/content/packaging/. The following are brief descriptions of the samples available:

 
All_Elements Illustrates a simple manifest using Content Packaging elements;
Extensions Illustrates a simple manifest with a comprehensive meta-data section that draws from the IMS Meta-Data specification;
Full_Metadata Illustrates a manifest that uses all elements and attributes defined in the IMS Content Packaging specification;
Multiple_Organizations Illustrates the use of multiple <organizations> to provide different paths through a course;
Simple_Manifest Illustrates a simple manifest;
Sub_Manifests Illustrates the use of (sub)Manifests to promote reuse. This example takes the Simple Manifest example, and implements it using (sub)Manifests;
\Test_Cases\Organization Illustrates a test manifest of different options for <organization>;
\Test_Cases\Resource Illustrates a test manifest of a possible way of addressing <resource>;

The W3C 'xml:' namespace definition file is available online but in cases where the parser does not have online, users may modify the schema to reference a local version of 'xml.xsd' that has been retrieved from W3C schema location and associated with the same namespace. In these cases the local version is a control document and as such it should be in the root directory along with the manifest file itself.

The filename of the Content Packaging control XSD only identifies the primary and secondary versions of the version i.e., for the v1.1.3 release the XSD filename is 'ims_cpv1p1.xsd'. The full version number is recorded in the 'version' attribute on the schema declaration e.g.

<xs:schema targetNamespace="http://www.imsglobal.org/xsd/imscp_v1p1" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" 
   elementFormDefault="qualified" version="IMS CP 1.1.3">

Appendix A - Additional Resources

IMS Content Documents

IMS Content Packaging Information Model: http://www.imsglobal.org/content/packaging/

IMS Content Packaging Best Practice Guide: http://www.imsglobal.org/content/packaging/

IMS Meta-data Documents

The IMS Meta-Data Best Practice and Implementation Guide: http://www.imsglobal.org/metadata/

The IMS Learning Resource Meta-Data Information Model: http://www.imsglobal.org/metadata/

ADL/AICC Documents

Sharable Content Object Reference Model (SCORMtm): http://www.adlnet.org/

Aviation Industry CBT Committee (AICC) API for Web Implementation: http://www.aicc.org/

XML

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

XML Inclusion Technical Report: http://www.w3.org/TR/xinclude

XML Schema specification of the W3C: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

About This Document

 
Title IMS Content Packaging XML Binding
Editor Colin Smythe
Team Co-Lead Adam Cooper
Version 1.1.3
Version Date 12 June 2003
Status Final Specification
Summary This document describes the IMS Content Packaging XML Binding that implements the IMS Content Packaging Information Model. The XML encoding is based on the W3C XML Specification 1.0.
Revision Information 12 June 2003
Purpose Defines the Content Packaging XML Binding.
Document Location http://www.imsglobal.org/content/packaging/cpv1p1p3/

List of Contributors

The following individuals contributed to the development of this document:

 
Name Organization
Thor Anderson Collegis
Jay Beavers Microsoft
Adam Cooper FD Learning
Rich Cushman SCT
Philip Dodds ADL
Steve Griffin IMS
Mike Halm Penn State
Alan Hoberney ADL
Chris Moffatt Microsoft
Boyd Nielsen NETg
Bill Olivier CETIS
Claude Ostyn Click2learn, Inc.
Mike Pettit Blackboard
Daniel Rehak Carnegie Mellon University
Tyde Richards IBM
Udo Schuermann Blackboard
Colin Smythe IMS
Schawn Thropp ADL
Tom Wason IMS
Bill Young Sun Microsystems
Kenny Young Microsoft

Revision History

 
Version No. Release Date Comments
Final 1.0 25 May 2000 Updated document to address the following open issues:
a) Explained basic differences between DTDs and other Schemas for document validation in both the Best Practice Guide and the Binding document;
b) Ensured that the samples provided with the specification are separated into different folders depending on whether a DTD or an XDR file is used as the control document. The samples used in the body of the specification documents are only well-formed and do not rely upon a particular control document;
c) Added a URL for where users can download the samples;
d) Made an explicit comment that none of the samples provided (wherever they occur) refer to any sort of control document;
e) Reordered the Appendices to fit the order they're mentioned in the specification documents.
Final 1.1 19 April 2001 Updated document to address the following open issues:
a) Clarified the use of the <organization> element in section 3.3.1;
b) Deprecated the use of XInclude: removed samples from Sections 4.6 and 4.7;
c) Extended meta-data functionality to <organization>, <item>, and <file>;
d) Changed the 'type' attribute on <organization> to 'structure' with a default value of 'hierarchical';
e) Added <dependency> element to Section 3.4.1.3;
f) Added sample of meta-data on <organization> to Section 3.3.4;
g) Deprecated the use of <manifestref> and moved (sub)Manifests out of the <resources> block;
h) Changed resource <item> element attribute back to 'identifierref' from 'resourceref';
i) Made several minor edits; changed references to sub-manifest to (sub)Manifest; updated the graphics;
j) Added <dependency> example to Section 3.4.1.3.
Final 1.1.1 23 May 2001 Updated XML-Schema sample in Binding Appendix B.
Final 1.1.2 08 August 2001 Made several editorial corrections, and:
a) Corrected references from a specific IMS Meta-Data version to just IMS Meta-Data;
b) Removed the copies of the DTD and XSD from the appendix for ease of updating in the future;
c) Removed references to XDR (XML Data Representation) schema, since it is no longer supported by Microsoft.
Final 1.1.3 12 June 2003 The changes contained within v1.1.3 are:
a) 'xml:' prefix recommendation - adoption of the W3C 'xml.xsd' file for the definition of the 'xml:' namespaced attributes available to the content package;
b) XML binding version identification attribute - clarification on the version numbering and corresponding namespace consequences for the content package XML schema;
c) ID and IDREF usage in the XML binding - clarification on the implications of the usage of the 'xsd:ID' and 'xsd:IDREF' features in the content package XML schema;
d) XML binding min/max constraints relaxation - removal of the min/max constraints that are currently incorrectly imposed within the content package XML schema;
e) 'parameter' attribute vocabulary - adoption of a syntax for the definition of the parameters as contained in the 'parameter' attribute plus definition of the algorithm to construct an associated URI;
f) 'isvisible' attribute clarification - clarification on the consequences on the rendering of the content and its title due to the usage of the 'isVisible' attribute;
g) 'type' attribute vocabulary - clarification on the usage of the 'webcontent' and other terms permitted for the 'type' attribute vocabulary
h) 'Href' filename format recommendation - formal definition of the file name formats that must be adopted when using the 'Href' attribute;
i) ZIP file format recommendation - formal definition of the ZIP file format that must be adopted;
j) Submanifest usage best practices clarification - clarification on the permitted referencing between a manifest and its contained (sub)Manifests.

Index

A
ADL 1
AICC 1
Attributes 1, 2, 3, 4, 5, 6, 7, 8
     default 1, 2, 3, 4
     href 1, 2
     identifier 1, 2, 3, 4, 5
     identifierref 1, 2
     isvisible 1, 2
     parameters 1, 2
     structure 1, 2, 3, 4, 5
     type 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     version 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     xml
 

base 1, 2, 3

C
CDATA 1, 2, 3, 4

D
DTD 1, 2, 3

E
Elements 1, 2, 3, 4, 5, 6, 7, 8, 9
     dependency 1, 2, 3
     file 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     item 1, 2
     manifest 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     metadata 1, 2, 3, 4, 5, 6, 7
     organization 1, 2, 3, 4, 5, 6, 7
     organizations 1, 2, 3, 4, 5, 6
     resource 1, 2, 3, 4, 5, 6, 7
     resources 1, 2, 3, 4, 5, 6, 7
     schema 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     schemaversion 1, 2
     title 1, 2
     variation 1
Extensibility 1
 

I
ISO 1, 2

M
Manifest 1, 2, 3, 4, 5, 6
Meta-data 1, 2

N
Names 1

O
Organizations 1

P
PCDATA 1, 2

R
Resources 1, 2, 3

S
Schema 1, 2, 3
Schemas 1, 2, 3, 4

U
Unicode 1

W
W3C 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

X
XInclude 1
XML 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
XML Features
     XInclude 1
XML Schema
     DTD 1, 2, 3
     XSD 1, 2, 3
XSD 1, 2, 3
 

Z
ZIP 1

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Content Packaging 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 Content Packaging XML Binding Revision: 12 June 2003