| IMS Content Packaging XML Binding Version 1.1.4 Final Specification

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Content Packaging XML Binding
Revision: 04 October 2004

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2004 IMS Global Learning Consortium. All Rights Reserved.

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

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.4 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.3 are compatible with CPv1.1.4 (with the exception of changing the XSD control document assignment in the header of the instance file). Instances that may not conform are those that have an <organization> element with 0 <item> elements.

## 1.2 Scope and Context

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

- IMS Content Packaging XML XSDs;
- IMS Content Packaging Best Practice and Implementation Guide [CP, 04c].

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

A list of future planned enhancements can be found in Appendix D of the Best Practice Guide [CP, 04c]

## 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, 04a] | IMS Content Packaging Information Model v1.1.4, C.Smythe, A.Jackl, IMS Global Learning Consortium, Inc., October 2004.
[CP, 04c] | IMS Content Packaging Best Practice and Implementation Guide v1.1.4, C.Smythe, A.Jackl, IMS Global Learning Consortium, Inc., October 2004.
[CP, 04d] | IMS Content Packaging Summary of Changes v1.1.4, C.Smythe, A.Jackl, IMS Global Learning Consortium, Inc., October 2004.
[IMSBUND, 01] | Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications v1.0, B.Olivier, M.McKell, IMS Global Learning Consortium, Inc., August 2001.
[MD, 04] | IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata v1.3, P.Barker, L.Campbell, A.Roberts, IMS Global Learning Consortium, Inc., May 2004.
[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.

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>

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:lom>
          <imsmd:general>
             <imsmd:title>
                <imsmd:langstring xml:lang="en-US">Simple Manifest</imsmd:langstring>
             </imsmd:title>
          </imsmd:general>
       </imsmd:lom>
    </metadata>

### 3.1.2 <organizations>

Description. Describes zero, one, or more structures or organizations (i.e., <organization> elements) for this package.

Figure 3.3 - <organizations> elements.

Multiplicity. Occurs once within a <manifest> element.

Attributes

- default (optional). 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 content files.

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:lom>
          <imsmd:general>
             <imsmd:title>
                <imsmd:langstring xml:lang="en-US">Simple Manifest</imsmd:langstring>
             </imsmd:title>
          </imsmd:general>
       </imsmd:lom>
    </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 one 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:lom>
             <imsmd:educational>
                <imsmd:interactivitylevel>1</imsmd:interactivitylevel>
             </imsmd:educational>
          </imsmd:lom>
       </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 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. These labels are defined in Section 7 of the Implementation Handbook titled 'Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications' [IMSBUND, 01]. An IMS specification may extend the table in section 7 by using the syntax and including a normative statement to that effect in the specification.
- 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 IEEE 1484.12.1-2002 Standard for Learning Object Metadata (see IMS Meta-Data v1.3 [MD, 04] for best practices and guidelines in implementing the IEEE LOM 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 [CP, 04c].

# 4. Samples

A number of supporting files accompany the IMS Content Packaging specification documents and are available in the download .zip file (imscp_v1p1p4.zip). The files in the zip file are as follows:

\imscp_infov1p1p4.pdf | IMS Content Packaging Information Model
\imscp_bindv1p1p4.pdf | IMS Content Packaging XML Binding (this document)
\imscp_bestv1p1p4.pdf | IMS Content Packaging Best Practice Guide
\imscp_sumcv1p1p4.pdf | IMS Content Packaging Summary of Changes
\schema\ imscp_v1p1.xsd | IMS Content XML Schema, version 1.1.4
\samples\All_Elements | Illustrates a simple manifest using Content Packaging elements.
\samples\QTI_Example | Illustrates a simple manifest packaging QTI elements.
\samples\Full_Metadata | Illustrates a manifest that uses all elements and attributes defined in the IMS Content Packaging specification.
\samples\Multiple_Organizations | Illustrates the use of multiple <organizations>, to provide different paths through a course.
\samples\Simple_Manifest | Illustrates a simple manifest.
\samples\Sub_Manifests | Illustrates the use of sub-Manifests to promote reuse. This example takes the Simple Manifest example, and implements it using sub-Manifests.

The W3C 'xml:' namespace definition file is available online but in cases where the parser does not have internet access, users may modify the schema to reference a local version of 'xml.xsd' that has been retrieved from W3C 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.4 release the XSD filename is 'ims_cpv1p1.xsd'. The full version number is recorded in the 'version' attribute on the schema declaration e.g.,:

    <xsd:schema targetNamespace="http://www.imsglobal.org/xsd/imscp_v1p1"
       xmlns:xsd="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.4">

# 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/

#### IEEE Documents

IEEE LTSC 1484.12 Learning Object Metadata: http://ltsc.ieee.org/wg12

#### 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
Editors | Colin Smythe (IMS), Alex Jackl (IMS)
Version | 1.1.4
Version Date | 04 October 2004
Status | Final Specification
Summary | This document describes the XML Binding that implements the IMS Content Packaging Information Model.
Revision Information | 04 October 2004
Purpose | This document has been approved by the IMS Technical Board and is made available for adoption.
Document Location | http://www.imsglobal.org/content/packaging/cpv1p1p4/imscp_bindv1p1p4.html

To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=5

## List of Contributors

The following individuals contributed to the development of this document:

Name | Organization | Name | Organization
--- | --- | --- | ---
Thor Anderson | Collegis | Boyd Nielsen | NETg
Jay Beavers | Microsoft | Bill Olivier | CETIS
Fred Beshears | UC Berkeley | Claude Ostyn | Click2learn, Inc.
Kerri Blinco | DEST | Mike Pettit | Blackboard
Lorna Campbell | JISC (CETIS) | Daniel Rehak | Carnegie Mellon University
Adam Cooper | FD Learning | Tyde Richards | IBM
Rich Cushman | SCT | GianLuca Rolandelli | GIUNTI
Philip Dodds | ADL | Udo Schuermann | Blackboard
Pierre Gorissen | SURF | James Simon | SUN Microsystems
Steve Griffin | IMS | Colin Smythe | IMS
Mike Halm | Penn State | Colin Tattersall | OUNL
Andy Heath | IMS Europe | Schawn Thropp | ADL
Alan Hoberney | ADL | Tom Wason | IMS
Alex Jackl | IMS | Raymond Yee | UC Berkeley
Wilbert Kraan | JISC (CETIS) | Bill Young | Sun Microsystems
Mladen Maljkovic | WebCT | Kenny Young | Microsoft
Chris Moffatt | 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.
Final 1.1.4 | 04 October 2004 | Made several editorial and clarifying corrections, and: a) Corrected inconsistent name-spacing using xml:lang and x:lang; b) Clarified conflicting information describing the <organizations> element; c ) Removed remaining references to the <variation> element; d) Coordinated Item element multiplicity between Info Model and Binding documents; e) Corrected all graphics to be consistent with the v1p1p4 schema.

# Index

A
Aggregation 1
Attributes
default 1
isvisible 1
parameters 1
structure 1
type 1
version 1, 2

B
Best Practice Guide 1, 2, 3, 4
Binding 1, 2, 3, 4, 5, 6, 7

C
Content Package 1, 2

D
Disaggregation 1
DTD 1

E
Elements
dependency 1
file 1, 2
item 1
manifest 1, 2
organization 1
resource 1
resources 1
schema 1, 2
title 1
Extensibility 1

I
IEEE 1, 2
IMS Specifications
Content Packaging 1, 2, 3, 4, 5, 6, 7, 8
Learner Information Package 1
Meta-Data 1, 2, 3, 4, 5
Question and Test Interoperability 1
Information Model 1, 2, 3
ISO 1, 2
isvisible 1, 2, 3

L
Learning 1
Learning Object 1
LOM 1
LTSC 1

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

N
Namespace 1
Normative 1, 2, 3

R
Resource 1, 2, 3, 4
Resources 1, 2, 3, 4, 5

S
Schema 1, 2, 3, 4, 5, 6, 7, 8
Schemas 1
Standards 1, 2, 3, 4
Structure 1, 2, 3, 4, 5
sub-Manifest 1

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

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

Z
ZIP 1
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: 04 October 2004