| IMS Content Packaging Best Practice and Implementation Guide 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 Best Practice and Implementation Guide
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. Stakeholders
3. Relationship to Other Specifications
3.1 Content Packaging
3.2 Data Model
3.3 Run Time Environment
4. Conceptual Model Discussion
4.1 Standard Name for the Manifest File
4.2 <manifest> Element
4.3 <metadata> Element
4.3.1 External Meta-Data
4.4 <organizations> Element
4.4.1 <organization> Element
4.4.2 Using Nested <manifest> Elements
4.5 <resources> Element
4.6 Examples of <resources> and Nested <manifest> Elements
4.7 Building an IMS Package or Package Interchange File
4.8 Aggregation and Disaggregation of Packages
4.8.1 Identifiers
4.8.2 XInclude
4.8.3 xml:base
4.8.4 Package Scope
4.8.5 <identifierref> Referenced Elements
4.9 Min/Max Binding Constraints
4.10 Using the 'isvisible' Attribute
5. Validation
5.1 W3C Schema Validation
6. Conformance
6.1 Package Conformance
6.1.1 Package Conformance Level 0 (no extensions)
6.1.2 Package Conformance Level 1 (utilizes extensions)
6.2 System and Tool Conformance
6.2.1 System and Tool Conformance Level 0 (may not preserve extensions)
6.2.2 System and Tool Conformance Level 1 (preserves extensions)
6.3 Best Practice Recommendations for IMS Package Conformance
Levels
7. Extensibility
7.1 Extending <metadata>
7.2 Extending <organizations>
7.3 Extending <resources>
7.4 Extending with DTDs
Appendix A - Supporting Files
Appendix B - Additional Resources
B1 - Various Documents
B2 - Namespacing and Schema Reference
Appendix C - Harmonization
Appendix D - Possible Future Directions
Appendix E - Glossary of Terms
E1 - General Terms
E2 - Content Packaging Elements and Attributes
About This Document
List of Contributors
Revision History
Index

# 1. Introduction

## 1.1 Overview

Instructional content often needs to be collected and packaged in some electronic form to enable efficient aggregation, distribution, management, and deployment. Producers of instructional materials want to have tools and technologies available to assist them in creating content. Software vendors in the online learning market want to create tools that enable efficient distribution and management of those instructional materials that have been created. Finally, learners are interested in high-quality learning experiences made possible by good deployment and delivery tools.

Content that is packaged in a known manner and file format, and with sufficient supporting information, can better satisfy the needs of the online learning community. This growing community needs guidelines and specifications for online learning content that will allow:

- Authors to build online learning content;
- Administrators to manage and distribute content;
- Learners to interact with and learn from the content.

A framework has been created with these goals in mind (Figure 1.1). The purpose of the IMS Content framework is to enable the encapsulation, in a concise and easily browsed manner, of all the required content resources, supporting information, and structure required to promote interoperable, online learning experiences.

Figure 1.1 IMS Content framework goals.

## 1.2 Scope and Context

This document is the IMS Content Packaging (CP) Best Practice and Implementation Guide. As such, it should be used in conjunction with:

- IMS Content Packaging Information Model v1.1.4 [CP, 04a];
- IMS Content Packaging XML Binding v1.1.4 [CP, 04b].

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 Summary of Changes document [CP, 04d].

Information on possible future development of the Content Packaging specification can be found in Appendix D of this document.

## 1.3 Structure of this Document

The structure of this document is:

2. Stakeholders | The relationship of this specification to its stakeholders;
3. Relationship to Other Specifications | The relationship of this specification activity to other IMS and external specification activities;
4. Conceptual Model Discussion | A brief summary of the Content Packaging Information Model;
5. Validation | A discussion of the usage of XSDs for validation;
6. Conformance | The expectations on systems that claim conformance to the Content Packaging specifications;
7. Extensibility | The ways in which proprietary extensions are supported through this specification;
Appendix A - Supporting Files | Files that accompany the IMS Content Packaging specification that are available for download;
Appendix B - Additional Resources | The additional resources relevant to Content Packaging;
Appendix C - Harmonization | Information and resources related to harmonization with other IMS specifications;
Appendix D - Future Enhancements | List of future enhancements
Appendix E - Glossary of Terms | A glossary of the key terms and elements used within the specification.

## 1.4 Nomenclature

ADL | Advanced Distributed Learning
AICC | Aviation Industry CBT Committee
API | Application Programming Interface
ANSI | American National Standards Institute
CBT | Computer Based Training
CMI | Computer Managed Instruction
CPI | Content Packaging Interchange
DTD | Document Type Definition
GUID | Globally Unique Identifier
IEEE | Institute of Electronic & Electrical Engineering
ISO | International Standards Organization
JTC | Joint Technical Committee
LMS | Learning Management System
LTSC | Learning Technology Standards Committee
SCORMTM | Sharable Content Object Reference Model
URI | Universal Resource Identifier
W3C | World Wide Web Consortium
XML | Extensible Mark-up Language
XSD | XML Schema Definition

## 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, 04b] | IMS Content Packaging XML Binding 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, W.Kraan, 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.
[IMSPLID, 01] | IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook v1.0, M.McKell, IMS Global Learning Consortium, Inc., April 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.
[MD, 901] | IMS Learning Resource Meta-data v1.2.1, S.Thropp, M.McKell, IMS Global Learning Consortium, Inc., September 2001.
[MD, 501] | IMS Learning Resource Meta-data v1.2, T.Anderson, M.McKell, IMS Global Learning Consortium, Inc., May 2001.

# 2. Stakeholders

There are a number of stakeholders who are contributing to and stand to benefit from an IMS Content Packaging specification derived from the IMS Content framework. These stakeholders have been grouped into the following categories:

- Content producers;
- Learning management system (LMS) vendors;
- Computing platform vendors;
- Learning service providers.

Content producers want to leverage their investment in online learning content. Members of this group include publishers, corporate training departments, online libraries, and instructors. LMS vendors want a wealth of content to be available for their systems to utilize. Computing platform vendors want to know the details of a specific format for a Content Package so that their software tools (authoring tools, presentation software, office suites, etc.) can import and export data based upon that format.

Learning service providers are those individuals, businesses, and institutions that buy, craft, deploy, and use the tools and products mentioned above. Members of this group include government initiatives and agencies, corporations, K-12 schools, higher education, internationalization companies, and many others.

Note: It is important that all of the stakeholders in this specification effort understand the difference between the technical requirements of such a specification and the learning requirements. This specification is neutral regarding the wide variety of instructional theories and approaches that may be used to design, develop, and evaluate content. The examples found near the end of this document demonstrate some particular approaches used for packaging and describing content that may be different from other approaches, but will still function properly within the specification parameters.

The IMS Content Packaging specification only deals with the description and structure of online learning materials and the definition of some particular content types. For example, this specification will not indicate pedagogical details such as how one might achieve a particular learning outcome. Nor will this specification advise developers in particular implementation details such as how to properly play an '.avi' file on a Macintosh.

# 3. Relationship to Other Specifications

The entire, extended scope of the IMS Content Packaging specification is complemented by the overall goals of the IMS Content framework. Those goals are to provide enough guidance, through this specification, that people may build, manage, and interact with interoperable, online learning materials.

The following historical work was considered in the development of the original version 1.1 framework:

- IMS API draft specification version 0.6 (6/98);
- IMS Packaging draft specification version 0.6 (2/99);
- The Aviation Industry CBT Committee's (AICC) API for Web Implementation of AICC/IEEE CMI specification (9/99);
- The Advanced Distributed Learning Initiative's (ADL) Sharable Content Object Reference Model (11/99);
- The Microsoft Learning Resource Interchange (LRN) specification (01/00).

The scope of the IMS Content specification was captured in a diagram through a series of meetings and group discussions. This expanded view of the Content scope is depicted in Figure 3.1.

Figure 3.1 IMS Content framework.

The complete, identified scope of the IMS Content framework is large and complex. To reduce the complexity and decrease the amount of time needed to complete a first specification, the scope was broken down into three, main parts: Content Packaging, Data Model, and Run Time Environment. Each of these topics requires additional explanation and each is described in more detail in the following sections.

## 3.1 Content Packaging

The IMS Content Packaging portion of the IMS Content framework represents the section that deals with the issues of content resource aggregation, course organization, and meta-data. All of the documents that comprise the IMS Content Packaging specification are focused on the scope represented in Figure 3.2.

Figure 3.2 - IMS Content Packaging scope.

## 3.2 Data Model

A future version of an IMS Content specification will address important, core issues of a general and extendable content data model. The data model represents that portion of the IMS Content framework where content is imported, stored, managed, and manipulated for instructional purposes. LMS vendors and computer platform vendors will play a key role in defining this portion of the specification.

A future IMS Content specification will also take into account how the IMS Enterprise, Question and Test Interoperability, and Learner Information Package specifications play a role in the data model. Other efforts such as the work that has been done within the ADL and AICC are being considered to determine which parts we can agree on that are common across all domains and which parts are specific to a particular community. The content team will also carefully determine a mechanism for how extensions to the data model may be represented so that different communities can use the IMS Content framework.

## 3.3 Run Time Environment

A future IMS Content specification will deal also with the issues surrounding run time environments. The run time environment portion of the IMS Content framework represents the point where learners will interact with the content presented to them. One of the key requirements for this portion of the specification will be the identification of standard mechanisms to enable communication between a run time environment and an LMS.

# 4. Conceptual Model Discussion

The IMS Package depicted in Figure 4.1 consists of two major elements: a special XML file describing the content organization and resources in a Package, and the file resources being described by the XML. The special XML file is called the IMS Manifest file, because course content and organization is described in the context of 'manifests'. Once a Package has been incorporated into a single file for transportation, it is called a Package Interchange File. The relationship of these parts to the content container is described below:

Package Interchange File - a single file, (e.g., '.zip', '.jar', '.cab') which includes a top-level manifest file named "imsmanifest.xml" and all other files as identified by the Manifest. A Package Interchange File is a concise Web delivery format, a means of transporting related, structured information. PKZip v2.04g (.zip) is recommended as the default Package Interchange File format. Any ZIP file format MUST conform to RFC1951.

Package - a logical directory, which includes a specially named XML file, any XML control documents it directly references (such as a DTD or XSD file), and contains the actual file resources. The file resources may be organized in sub-directories.

- Top-level Manifest - a mandatory XML element describing the Package itself. It may also contain optional sub-Manifests. Each instance of a manifest contains the following sections:
  - Meta-data section - an XML element describing a manifest as a whole;
  - Organizations section - an XML element describing zero, one, or multiple organizations of the content within a manifest;
  - Resources section - an XML element containing references to all of the actual resources and media elements needed for a manifest, including meta-data describing the resources, and references to any external files;
  - sub-Manifest - one or more optional, logically nested manifests;
- File Resources - these are the actual media elements, text files, graphics, and other resources as described by the manifest(s). The file resources may be organized in sub-directories.

Package - A Package represents a unit of usable (and reusable) content. This may be part of a course that has instructional relevance outside of a course organization and can be delivered independently, as an entire course or as a collection of courses. Once a Package arrives at its destination to a run time service, such as an LMS vendor, the Package must allow itself to be aggregated or disaggregated into other Packages. A Package must be able to stand alone; that is, it must contain all the information needed to use the contents for learning when it has been unpacked.

Packages are not required to be incorporated into a Package Interchange File. A Package may also be distributed on a CD-ROM or other removable media without being compressed into a single file. An IMS Manifest file and any other supporting XML files directly referenced by it (DTD, XSD) must be at the root of the distribution medium.

Manifest - A manifest is a description in XML of the resources comprising meaningful instruction. A manifest may also contain zero or more static ways of organizing the instructional resources for presentation.

The scope of manifest is elastic. A manifest can describe part of a course that can stand by itself outside of the context of a course (an instructional object), an entire course, or a collection of courses. The decision is given to content developers to describe their content in the way they want it to be considered for aggregation or disaggregation. The general rule is that a Package always contains a single top-level manifest that may contain one or more sub-Manifests. The top-level manifest always describes the Package. Any nested sub-Manifests describe the content at the level to which the sub-Manifest is scoped, such as a course, instructional object, or other.

For example, if all content comprising a course is so tightly coupled that no part of it may be presented out of the course context, a content developer would want to create a single manifest to describe that course's resources and organization. However, content developers who create "instructional objects" that could be recombined with other instructional objects to create different course presentations would want to describe each instructional object in its own manifest, then aggregate those manifests into a higher-level manifest containing a course organization. Finally, a content developer who wants to move multiple courses in a single Package (a curriculum), would use a top-level manifest to contain each course-level manifest and any instructional object manifests that each course might contain.

Resource - The resources described in the manifest are assets such as Web pages, media files, text files, assessment objects or other pieces of data in file form. Resources may also include assets that are outside the Package but available through a URL, or collections of resources described by sub-Manifests. The combination of resources is generally categorized as content. Each resource may be described in a <resource> element within a manifest's XML. This element includes a list of all the assets required to use the resource. The files included in the Package are listed as <file> elements within such <resource> elements.

While all content should be referenced in the resource section of the manifest, it is not necessary for all declared resources in a manifest to be referenced by <item> elements in the <organization> section of a manifest. This feature can be useful in two cases:

- When a file needs to be included that does not need to be presented to the learner;
- When the package is used as a content archive that is not designed to be presented to a learner.

## 4.1 Standard Name for the Manifest File

Content distributed according to the IMS Content Packaging specification must contain an IMS Manifest file. To ensure that the IMS Manifest file can always be found within a Package, it has a pre-defined name and location:

imsmanifest.xml

In the absence of this file, the package is not an IMS Package and cannot be processed. It is required that the name be kept, as above, in all lowercase letters.

The IMS Manifest file and any of its directly referenced XML control files (DTD, XSD) must be placed at the root of the Package Interchange File or any other packaging image (like a CD-ROM). XML control files that are indirectly referenced can be located as required by the namespace and path names. The usage of remote or local validation files is implementation dependent.

However, if local files are used then these must be identical to those online. If "local" validation is going to be performed using a local copy of the W3C xml.xsd and the validation process is going to be done in a "disconnected" environment, then "local" versions (i.e., copy of) of the following files will also be needed: datatypes.dtd and XMLSchema.dtd. These DTDs are used by the W3C provided xml.xsd and can be obtained from the W3C.

## 4.2 <manifest> Element

The organization of file resources within a Package is independent of their use. The <manifest> element in an IMS Manifest file serves the purpose of organizing the content for presentation in one or more presentation structures or views and of specifying the resource(s) supporting each view. In this way, a <manifest> element relieves the Package's internal file structure from having to reflect the organization of resources for aggregation or disaggregation. Each resource or set of resources supporting a given presentation view is described for that view, including the path to each file through any internal folders or sub-directories comprising the internal file structure. A Manifest may provide one or more static views of the content.

A single <manifest> element is required as the root element of the IMS Manifest file. There can be one and only one top-level <manifest> element. All other instances of a <manifest> element are nested within the <manifest> element after the <resources> element. The information model does not impose a particular ordering within the <manifest> element however the corresponding XML binding does impose the implied order of: <metadata>, <organizations>, <resources> and <manifest>.A manifest contains four sub-elements: <metadata>, <organizations>, and <resources>, and any further <manifest> elements.

- <metadata> - (optional) this meta-data describes the manifest that contains it. Commonly used meta-data would include elements like title, description, keywords, a contributor's role, a content's purpose (e.g., educational objective, skill level), and copyright information. Meta-data elements should be drawn first from 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). Any meta-data elements not found in the IEEE 1484.12.1-2002 Standard for Learning Object Metadata could then be included via an XML namespace in a manifest's meta-data element(s). All meta-data elements must be defined in a DTD or XSD, which are declared at the top of the IMS Manifest file. Directly referenced meta-data DTD or XSD files can be included with imsmanifest.xml at the root of a Package's internal file structure.
- <organizations> - (required) contains zero, one, or multiple descriptions of the static organization of the content so that resources within the Package can be moved to create one or multiple organizations of content (such as course outlines). It is left to the discretion of content producers to decide whether to describe or not describe the organization of a course's resources. If content producers choose to provide one or more descriptions of a course's organization, they must also specify one as the default. The current Content Packaging XSD requires a single <organizations> element as a child of the <manifest> element. If content producers do not need an organizations section in the manifest, then it must appear as an empty element (i.e., "<organizations/>") to satisfy the control rules expressed in the controlling documents (DTD, XSD). Also, only one <organizations> element is allowed within each <manifest> element. The current specification defines an <organization> sub-element as one that uses a hierarchical organization; however, other ways of describing the organizational structure or content (such as conditional/programmatic) are permitted.
- <resources> - (required) includes references to all of the resources included in the package. At a minimum it should reference all those files that are needed in order to view the content as specified in the <organizations> element. References may either be made internally or externally of a Package to both relative and absolute identifiers. For example, a reference to an external URL is permitted without having to include that resource as part of the Package Interchange File. Resources may also contain a <metadata> element for each content item referenced. Only one <resources> element is allowed within the top-level <manifest> element.
- <manifest> - (optional) specifies zero or more sub-Manifests. Nested <manifest> elements specify how content may be reliably aggregated or disaggregated into other Packages.

The following sections describe these more fully.

## 4.3 <metadata> Element

Meta-data is optional and is allowed in various places in the manifest to more fully describe the contents of a Package. Search engines may look into the meta-data to find appropriate content for a learner or for content repackaging. Copyright and other intellectual property rights are easily declared within the meta-data. Authoring or editing tools could then read the rights stipulated by a content vendor to see if they have permission to open a resource file or files and change the contents.

The IMS CP Information model defines five places where meta-data can be used to describe different components of a content package:

1. Manifest
2. Organization
3. Item
4. Resource
5. File

If there are requirements to describe any or all of these components with meta-data, then each of these respective components shall be described with separate instances of Meta-data. This construct allows a fine-grained description of each component of a package.

Beware, however, that there is no assumption of inheritance from one logical node to another. Each component, if desired, is represented by its own meta-data instance. If the meta-data associated with a resource X, for example, identifies Jane Smith as the author, it does not follow that file Y, a child node of resource X without meta-data, is also authored by Jane Smith. In this case, if Jane needs to be identified as the author of file Y, a separate meta-data instance needs to be associated with file Y.

The complete set of meta-data elements available for describing and cataloging a content Package is not included with this specification. This specification recommends the best practice of using 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), which contains approximately 86 individual meta-data elements that may be used to describe and catalog Content Packages, as the Package author sees fit.

### 4.3.1 External Meta-Data

A Content Packaging implementation may, but does not need to, include an extension that references an external meta-data file. This version of the Content Packaging specification does not specify or recommend such a mechanism, but future versions of the Content Packaging specification may address the issue. An example of an in-line extension that refers to an external meta-data file is demonstrated by the following fragment:

       <metadata>
          <schema>ADL SCORM</schema>
          <schemaversion>CAM 1.3</schemaversion>
          <adlcp:location>Lesson01.xml</adlcp:location>
       </metadata>

This example is taken from the ADL SCORM 2004 profile.

## 4.4 <organizations> Element

There are many ways to organize course or Package content, including no organization at all. In a manifest file, the <organizations> element contains this information.

It is possible to imagine organizations that will take into account such approaches as hierarchical branching, indexes, custom learning paths utilizing conditional branching, and complex objective hierarchies. If the course or Package presentation does not require a specific organization, the <organizations> element is still necessary and must appear as follows to satisfy the control rules expressed in the XSD: <organizations/>. However, in this case the <organizations> element is left empty.

While many content organization approaches may be developed, a default approach is included as part of this specification. This default approach to content organization, similar to a tree view or hierarchical representation, is encompassed in the <organization> element. The <organization> element is the only element allowed under <organizations>. Content may have additional organization schemas, through the use of the type attribute by setting it to a non-default value. There can be multiple organizations and more than one of the same type, but only one specified as the default.

### 4.4.1 <organization> Element

The <organization> element contains information about one particular, passive organization of the material. The <organization> element assumes a default structure attribute value of hierarchical, such as is common with a tree view or structural representation of data. Future versions of the specification will likely include additional values for the structure attribute to correspond with additional structural organizations or shapes, such as a directed graph, a semantic network, or others. Until additional values are agreed upon, the <organization> element, by default, effectively reads: <organization structure=hierarchical>.

If there is more than one <organization> element within the same <organizations> element, then it is expected that they should be variant organizations with substantially the same learning outcomes. Material with substantially different objectives should appear in separate Packages. It should always be the case that the meta-data at the <manifest> element level describe the purpose of the Package as a whole.

Where an <organizations> element contains multiple <organization> elements, the following procedure is recommended, if one <organization> is to be selected for any reason:

- If there is a value given for the default attribute of <organizations>, then this identifies the organization to be used. This is the preferred method for identifying a particular <organization>;
- If there is no default given, then the first <organization> element encountered should be used.

Software that processes a Content Package may use the above procedure or it may:

- Use organization-level meta-data to make a selection, using its own rules;
- Allow users to select the organization;
- Use any other suitable approach.

The presentation structure of <organization> is described through <item> sub-elements. An <item> may contain subordinate <item> elements (a hierarchical approach to presentation) or may appear on the same level as other <item>s (a flat approach). A tree view, or hierarchical representation, may be defined by the nesting levels of the <item> elements. Content developers can mix and match nesting levels as appropriate for their content. An <item> always has an identifier, and is linked to resources through an identifierref attribute. Titles are optional, but encouraged. The <item> element may also be visible or hidden, the default presence is visible.

Authors may also include meta-data within the <organization> and <item> elements allowing them to describe additional information meaningful for searching or for indexing in a repository.

Example: A hierarchical organizational scheme for a manifest can be determined by the order and nesting of the <item> elements contained within the <organization> element, similar to the following:

    <organization identifier="TOC1">
       <title>Default Organization</title>
       <item identifier="ITEM1" identifierref="RESOURCE1">
          <title>Lesson 1</title>
       </item>
          <item identifier="ITEM2" identifierref="RESOURCE2">
             <title>Lesson 2</title>
          </item>
       <item identifier="ITEM3" identifierref="RESOURCE3">
          <title>Lesson 3</title>
       </item>
    </organization>

An LMS or content viewer encountering this structural organization or hierarchical tree view of the content could interpret it conceptually as:

- Lesson 1
  - Lesson 2
- Lesson 3

### 4.4.2 Using Nested <manifest> Elements

The mechanism for referencing an <item> element's resource is the 'identifierref' attribute, which is used to reference resources. Certain restrictions are placed on the kinds of references that can be made in order to maintain the capability for future disaggregation of a compound Manifest, including:

- An <item> element's identifierref can reference resources found in a subordinate <manifest> element in which it is contained. It can also reference the resources of any nested <manifest>;
- The reverse is not true: An <item> element's identifierref cannot refer to a <manifest> element that is higher than the <manifest> element that contains it, or to any resource referred to by a higher-level <manifest> element. If it were to do so, such references could not be resolved should the contained Manifest be disaggregated and used to create a different Package. If content producers need to reference a separate, external Package, they must first aggregate it and then point down to it;
- An <item> element's identifierref can reference a sub-Manifest.

## 4.5 <resources> Element

The <resources> element identifies a collection of content and its files. Individual resources are declared as a <resource> element nested within the <resources> element. A <resource> is not necessarily a single file. It may be a collection of files that support the presentation of the associated presentation structure (<item> element). These files may be internally referenced or externally referenced via a URL. Internally referenced files must be included in the Package Interchange File.

A <resource> element may also have a <metadata> sub-element. The <metadata> element is for the <resource>, whether it is a single file or a collection of files.

A <file> element may contain a <metadata> sub-element allowing authors to describe additional <file> information meaningful for searching or for indexing in a repository. A <resource> may reference an internal (or local) file by a relative URL as the href or as an external file or service by a fully-qualified remote URL. Internal files used by the resource are either directly enumerated by <file> elements or indirectly enumerated by using the <dependency> element to reference another resource. For example, the union of all file enumerations in a Package identifies all files (excluding binding control documents and imsmanifest.xml files) that must be communicated on transmission of a content Package. External referents do not form part of the Package and do not appear in <file> elements.

A <resource> element may also contain a <dependency> sub-element. The <dependency> element identifies a single resource which can act as a container for multiple files that this resource depends upon. Rather than having to list all resources item by item each time they are needed, <dependency> allows authors to define a container of resources and to simply refer to that <dependency> element instead of individual resources. The same restrictions on the values of the identifierref attribute apply to <dependency> as apply to <item> (see Section 4.4.2 for further guidance), with the exception of referring to resources in sub-Manifests. An <item> can do this, a <dependency> can't. Below is an example of using <dependency>.

    <resources>
       <resource identifier="R_A1" type="webcontent" href="sco06.html">
          <metadata/>
          <file href="sco06.html" />
          <file href="scripts/APIWrapper.js" />
          <file href="scripts/Functions.js" />
          <dependency identifierref="R_A4" />
          <dependency identifierref="R_A5" />
          <dependency identifierref="R_A6" />
       </resource>
       <resource identifier="R_A2" type="webcontent" href="sco1.html">
          <metadata/>
          <file href="sco1.html" />
          <file href="scripts/APIWrapper.js" />
          <file href="scripts/Functions.js" />
          <dependency identifierref="R_A5" />
       </resource>
       <resource identifier="R_A4" type="webcontent" href="pics/distress_sigs.jpg">
          <metadata/>
          <file href="pics/distress_sigs.jpg" />
       </resource>
       <resource identifier="R_A5" type="webcontent" href="pics/distress_sigs_add.jpg">
          <metadata/>
          <file href="pics/distress_sigs_add.jpg" />
       </resource>
       <resource identifier="R_A6" type="webcontent" href="pics/nav_aids.jpg">
          <metadata/>
          <file href="pics/nav_aids.jpg" />
       </resource>
    </resources>

The 'type' attribute is usually set to 'webcontent' when describing material that is to be launched through a Web browser. However, when a Content Package is being used to contain data such as a QTI-XML based assessment then the value of the 'type' attribute should be set as recommended in Section 7 of the Implementation Handbook titled 'Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications' [IMSBUND, 01]. The 'type' attribute is set to 'imsldcontent' when used to contain learning design information. In situations where none of the previous methods are appropriate, then this attribute should be set to 'other'.

Apart from the usage of the vocabulary in the Implementation Handbook it is recommended that this vocabulary is NOT extended. Later versions of this specification will address the extension of this vocabulary.

## 4.6 Examples of <resources> and Nested <manifest> Elements

There is an example available for download from the IMS website that illustrates how to describe in-line sub-Manifests. You can find this sample and others at http://www.imsglobal.org/content/packaging/. For an example of how external sub-Manifests may be described in a future version of the specification, see Appendix D.

## 4.7 Building an IMS Package or Package Interchange File

- Any namespaces required within a Package should be declared as attributes of the top-level <manifest> element;
- The imsmanifest.xml file and any files supporting namespaces (DTD, XSD) that are referenced internally must be placed at the root of the Package or compressed Package Interchange File;
- All internally referenced files must be stored in the paths declared in all <resource> elements in a Package.

## 4.8 Aggregation and Disaggregation of Packages

If a simple (non-aggregated) Package is to be aggregated into a new (super-)Package, first its manifest must be accessed and its list of <resource> elements obtained. These are traversed and each of their <file> elements examined to determine whether they reference external or internal files (note that any base address attribute in the <resources> elements and any overriding base address attributes in each <resource> element, need to be prefixed to a <file> element's file references). This is used to build a list of all the files contained locally in the Package that is being aggregated. This list in turn, is then used to access each file and to create a copy of it in the new Package. Next, the manifest of the Package being aggregated must be integrated as a subordinate <manifest> element into the manifest that is being created for the containing Package. When the construction of the new Package is complete, the containing manifest is saved as a file with the name imsmanifest.xml at the root of the new Package Interchange File.

If a Package is to be disaggregated from a containing Package into a smaller, sub-Package, first that sub-Package's <manifest> element must be accessed in the containing imsmanifest.xml file. The <resources> section of the accessed manifest is then read to determine the physical files that were originally contained in that section. This list is then used to locate these files in the larger Package and these are then copied to the new, smaller Package. The accessed manifest is then saved as a file with the name imsmanifest.xml and also included at the root of the new Package Interchange File.

If a compound Package, containing aggregated sub-Packages, is itself to be aggregated, then the same procedure is followed; with the addition that the compound Package's sub-Manifest elements also have to be walked in order to build a complete list of files referenced in all the sub-Manifests. As the aggregated Package's manifest already contains all the nested sub-Manifests, only this manifest needs to be merged into the new containing manifest. Similarly, if a compound sub-Package is to be disaggregated, its sub-Manifest tree needs to be walked in order to build the complete list of files that need to be copied into the disaggregated Package.

Packages, specifically organizational items, may not reference Package elements (<resource> elements) that are outside the Package scope. Referenced elements must be contained in the same Package from which they were referenced, including elements that are in sub-Packages within the Package. This specification does not contain rules as to how such referenced elements should be maintained by aggregation and disaggregation tools. The issue of intellectual property rights, concerning how resources preserve their original, unique identifiers is beyond the scope of this version of the Content Packaging specification.

### 4.8.1 Identifiers

When creating or manipulating Packages, the scope of identifiers needs to be considered. In order to be a valid Content Packaging Manifest, identifiers must be unique. If a Package is aggregated into another Package, identifier collisions could be avoided or resolved by using universally unique identifiers across manifests (such as identifiers generated or obtained according to the IMS Persistent, Location-Independent Resource Identifier Handbook [IMSPLID, 01]). If universally unique identifiers are not used in a system's own storage scheme, Packages should not be exchanged with other systems without building unique identifier generation into tools that support Package aggregation.

The XML binding uses the XML structures 'xsd:ID' and 'xsd:IDREF' to validate the uniqueness of the identifiers. This ensures that the identifiers are unique within the XML document and that any identifier referenced using 'IDREF' must have a corresponding 'ID' declaration within the XML document. The usage of 'ID' and IDREF' do not ensure globally unique identifiers and so care needs to be taken when using package aggregation. It is also important that the 'ID' declaration for the identifier is passed into a newly aggregated package otherwise a parser validation error will occur.

### 4.8.2 XInclude

The IMS Content Working Group expects that the XInclude mechanism, when fully approved and supported by the W3C, may prove a powerful way to support the aggregation and disaggregation of Package resources. However, authors should not use XInclude in packaging content until the W3C finalizes XInclude as a Recommendation and the XML community generally supports it.

Note: XInclude is mentioned here as an emerging standard that IMS will likely leverage in future versions of the Content Packaging specification rather than invent another way of including external XML files. See Appendix D for examples of how XInclude might be used in future versions of this specification.

### 4.8.3 xml:base

'xml:base' is a construct used to explicitly specify the base URI of a document in resolving relative URIs in links to external files. In the 'imsmanifest.xml' file, internal and external references may be absolute or relative. Relative addresses can be prefixed by an 'xml:base' attribute. The 'xml:base' attribute allows both external and local base addresses to be specified. Relative URLs, in the absence of 'xml:base', are relative to the Package root (location of 'imsmanifest.xml'). In the presence of an 'xml:base' path, relative URLs are relative to the path specified in 'xml:base'. When an 'xml:base' path is relative itself, the absolute path is then resolved to the location of the containing document. That is, the location of the 'imsmanifest.xml' file in an importing system, when it is read, supplies the missing absolute segment, per the rules expressed in RFC 2396.

Relative 'xml:base' paths that are declared in a sub-manifest are relative to the Package root. In cases where a manifest with a declared 'xml:base' path contains a sub-manifest, and the sub-manifest also declares an 'xml:base' path, the multiple 'xml:base' paths should not be concatenated at runtime. Instead, the URIs within such a sub-manifest are relative to the declared xml:base of the sub-manifest only. Implementors are, of course, free to construct a relative sub-manifest 'xml:base' path by concatenation or any other means at aggregation time.

In the presence of an xml:base path, which references an external location, the relative URLs are relative to that location. Absolute (external) URLs are considered to be fully-specified without the provision of additional pathing

When the 'xml:base' attribute is used, care must be taken not to exceed the length of any associated 'href'. The maximum length of both 'href' and 'xml:base' is defined as 2000 octets. In cases where multiple 'xml:base' values need to be concatenated to create the full path then care must be taken to ensure that the total length does not exceed that of the 'href'. If the path length is greater than 2000 octets then the system behavior is undefined.

When using xml:base in packaging, the xml:base path should not begin with a leading forward slash. As defined in RFC 2396, a path with a leading forward slash indicates the absolute path of that resource. Using a leading forward slash can easily be misinterpreted as declaring the document as the local host. With this in mind, the xml:base attribute is most useful for specifying relative paths to sub-directories containing content Package resources. Below is an example of using xml:base to specify the path to resources that are internal and relative.

    <manifest xmlns = "http://www.imsglobal.org/xsd/imscp_v1p1"
       xmlns:imsmd = "http://www.imsglobal.org/xsd/imsmd_v1p2"
       xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation = "http://www.imsglobal.org/xsd/imscp_v1p1
          http://www.imsglobal.org/xsd/imscp_v1p1.xsd
          http://www.imsglobal.org/xsd/imsmd_v1p2
          http://www.imsglobal.org/xsd/imsmd_v1p2.xsd "
          identifier="Manifest1-CEC3D3-3201-DF8E-8F42-3CEED12F4198"
           version="IMS CP 1.1.4">

       <metadata>
          <schema>IMS Content</schema>
          <schemaversion>1.1</schemaversion>
          <imsmd:lom>
             <imsmd:general>
                <imsmd:title>
                   <imsmd:langstring xml:lang="en_US">IMS Content Packaging Sample - A Relative
    xml:base</imsmd:langstring>
                </imsmd:title>
             </imsmd:general>
          </imsmd:lom >
       </metadata>
       <organizations default="TOC1">
          <organization identifier="TOC1">
             <title>default</title>
             <item identifier="ITEM1" identifierref="RESOURCE1">
                <title>Lesson 1</title>
                <item identifier="ITEM2" identifierref="RESOURCE2">
                   <title>Introduction 1</title>
                </item>
                <item identifier="ITEM3" identifierref="RESOURCE3">
                   <title>Content 1</title>
                </item>
                <item identifier="ITEM4" identifierref="RESOURCE4">
                   <title>Summary 1</title>
                </item>
             </item>
             <item identifier="ITEM5" identifierref="RESOURCE5">
                <title>Lesson 2</title>
                <item identifier="ITEM6" identifierref="RESOURCE6">
                   <title>Introduction 2</title>
                </item>
                <item identifier="ITEM7" identifierref="RESOURCE7">
                   <title>Content 2</title>
                </item>
                <item identifier="ITEM8" identifierref="RESOURCE8">
                   <title>Summary 2</title>
                </item>
             </item>
          </organization>
       </organizations>
       <resources>
          <resource identifier="RESOURCE1" type="webcontent" href="lesson1.htm" xml:base="lesson1/">
             <file href="lesson1.htm"/>
             <file href="picture1.gif"/>
          </resource>
          <resource identifier="RESOURCE2" type="webcontent" href="intro1.htm" xml:base="lesson1/">
             <file href="intro1.htm"/>
             <file href="picture2.gif"/>
          </resource>
          <resource identifier="RESOURCE3" type="webcontent" href="content1.htm" xml:base="lesson1/">
             <file href="content1.htm"/>
             <file href="picture3.gif"/>
          </resource>
          <resource identifier="RESOURCE4" type="webcontent" href="summary1.htm" xml:base="lesson1/">
             <file href="summary1.htm"/>
             <file href="picture4.gif"/>
          </resource>
          <resource identifier="RESOURCE5" type="webcontent" href="lesson2.htm" xml:base="lesson2/">
             <file href="lesson2.htm"/>
             <file href="picture1.gif"/>
          </resource>
          <resource identifier="RESOURCE6" type="webcontent" href="intro2.htm" xml:base="lesson2/">
             <file href="intro2.htm"/>
             <file href="picture2.gif"/>
          </resource>
          <resource identifier="RESOURCE7" type="webcontent" href="content2.htm" xml:base="lesson2/">
             <file href="content2.htm"/>
             <file href="picture3.gif"/>
          </resource>
          <resource identifier="RESOURCE8" type="webcontent" href="summary2.htm" xml:base="lesson2/">
             <file href="summary2.htm"/>
             <file href="picture4.gif"/>
          </resource>
       </resources>
    </manifest>

The following is an example of using xml:base to specify the path to resources that are external and absolute.

    <?xml version="1.0"?>
    <manifest identifier="MANIFEST1" xmlns="http://www.imsglobal.org/xsd/ims_cp_rootv1p1">
       <metadata>
          <schema>IMS Content</schema>
          <schemaversion>1.1</schemaversion>
          <imsmd:lom>
             <imsmd:general>
                <imsmd:title>
                   <imsmd:langstring xml:lang="en_US">IMS Content Packaging Sample - A Remote
    xml:base</imsmd:langstring>
                </imsmd:title>
             </imsmd:general>
          </imsmd:lom>
       </metadata>
       <organizations default="TOC1">
          <organization identifier="TOC1">
             <title>Big Title</title>
             <item identifier="ITEM1" identifierref="RESOURCE1">
                <title>Lesson 1</title>
                <item identifier="ITEM2" identifierref="RESOURCE2">
                   <title>Introduction 1</title>
                </item>
                <item identifier="ITEM3" identifierref="RESOURCE3">
                   <title>Content 1</title>
                </item>
                <item identifier="ITEM4" identifierref="RESOURCE4">
                   <title>Summary 1</title>
                </item>
             </item>
          </organization>
       </organizations>
       <resources xml:base="http://repository.imsglobal.org/foo/bar/">
          <resource identifier="RESOURCE1" type="webcontent" href="lesson1.htm"/>
          <resource identifier="RESOURCE2" type="webcontent" href="intro1.htm"/>
          <resource identifier="RESOURCE3" type="webcontent" href="content1.htm"/>
          <resource identifier="RESOURCE4" type="webcontent" href="summary1.htm"/>
       </resources>
    </manifest>

### 4.8.4 Package Scope

The scoping rules for manifests and sub-manifests is shown in Figure 4.1.

Figure 4.1 Scoping rules for sub-manifests.

The scope of Package 1's manifest is considered to be itself and any sub-Manifests defined within Package 1. This includes the manifest of Package 1 (Manifest 1) and any sub-manifests found in the sub-packages - Manifest 1.1 and Manifest 1.2.

The scope of Package 1.1's manifest is itself and any sub-Manifests defined within Package 1.1. This includes the manifest of Package 1.1 (Manifest 1.1) and any sub-Manifests defined within Package 1.1. In Figure 4.1 there are no sub-Manifests defined in Package 1.1, so the scope is itself.

The scope of Package 1.2's manifest is itself and any sub-Manifests defined within Package 1.2. This includes the manifest of Package 1.2 (Manifest 1.2) and any sub-Manifests defined within Package 1.2. In Figure 4.1 there are no sub-Manifests defined in Package 1.2, so the scope is itself.

Packages, specifically organizational items, may not reference manifests elements (<resource> elements) that are outside the scope of manifest. Referenced elements must be contained in the same manifest from which they were referenced, including elements that are in sub-manifests within the Package. In the case above, Package 1 manifest's elements can reference elements found in sub-Manifest 1.1 and sub-Manifest 1.2, since these are in scope of Package 1's manifest. sub-Manifest 1.1 and sub-Manifest 1.2 can only reference manifest elements within itself. Sub-Manifests elements are prohibited from referencing (dashed lines above) manifest elements in any manifests in which they are contained (child manifests elements are not permitted to reference elements in any parent manifests).

While it is currently permitted for an 'item' in the parent manifest to reference a specific 'resource' in a sub-Manifest (the reference to 'resource' R1.1 in Figure 4.1), it is debatable whether or not this is good practice. This is because alternative XML schemes are available to support such a referencing mechanism and so it is possible that this form of direct reference will be disallowed in later versions of this specification.

### 4.8.5 <identifierref> Referenced Elements

The following elements can be referenced using the identifierref attribute of an item:

- Identifier attribute of a manifest (references the entire manifest that is in scope of the referencing manifest);
- Identifier attribute of a resource (references the resource found in a sub-Manifest that is in scope of the referencing manifest);
- Identifier attribute of an item (references the item found in a sub-Manifest that is in scope of the referencing manifest);
- Identifier attribute of an organization (references the organization found in a sub-Manifest that is in scope of the referencing manifest).

## 4.9 Min/Max Binding Constraints

In the Content Packaging Information Model the concept of min/max was adopted. This concept assumes that the size constraints are defined such that an implementation must support the given value as the smallest possible maximum size. In the case of an identifier with a min/max size of 1000 characters then the smallest maximum size of the identifier supported in each and every implementation is 1000 characters. Some implementations may support larger sizes but interoperability is defined such that only the first 1000 characters is guaranteed to be exchanged consistently.

This constraint is not enforced in the XML schema (XSD). Therefore a validating parser cannot enforce the constraint as defined by the Information Model. Therefore, system implementations must be such that all min/max constraints are explicitly supported.

## 4.10 Using the 'isvisible' Attribute

The 'isvisible' attribute is used to denote if the 'item' is to be visible when the organization tree is rendered for the 'user' by the system. The default value for 'isvisible' is 'true' and this must be assumed if the attribute is not used on the 'item'. This property is not inherited by the children of an 'item'. Some examples of the rendering is shown in the following Table 4.1.

Table 4.1 - Examples of using the 'isvisible' attribute.

Example XML Code | Rendered Items
--- | ---
    <item identifier="1">
       <title>A</title>
       <item identifier="2">
          <title>B</title>
          <item identifier="3">
             <title>C</title>
          </item>
       </item>
       <item identifier="4">
          <title>D</title>
       </item>
    </item>
    <item identifier="5">
       <title>E</title>
    </item>
| A B C D E
    <item identifier="1" isvisible="false">
       <title>A</title>
       <item identifier="2">
          <title>B</title>
          <item identifier="3">
             <title>C</title>
          </item>
       </item>
       <item identifier="4">
          <title>D</title>
       </item>
    </item>
    <item identifier="5">
       <title>E</title>
    </item>
| B C D E
    <item identifier="1" isvisible="false">
       <title>A</title>
       <item identifier="2" isvisible="true">
          <title>B</title>
          <item identifier="3" isvisible="true">
             <title>C</title>
          </item>
       </item>
       <item identifier="4" isvisible="true">
          <title>D</title>
       </item>
    </item>
    <item identifier="5" isvisible="true">
       <title>E</title>
    </item>
| B C D E
    <item identifier="1" isvisible="true">
       <title>A</title>
       <item identifier="2" isvisible="false">
          <title>B</title>
          <item identifier="3" isvisible="false">
             <title>C</title>
          </item>
       </item>
       <item identifier="4" isvisible="false">
          <title>D</title>
       </item>
    </item>
    <item identifier="5" isvisible="false">
       <title>E</title>
    </item>
| A
    <item identifier="1" isvisible="true">
       <title>A</title>
       <item identifier="2" isvisible="false">
          <title>B</title>
          <item identifier="3" isvisible="true">
             <title>C</title>
          </item>
       </item>
       <item identifier="4" isvisible="false">
          <title>D</title>
       </item>
    </item>
    <item identifier="5" isvisible="false">
       <title>E</title>
    </item>
| A C
    <item identifier="1" isvisible="true">
       <title>A</title>
       <item identifier="2" isvisible="true">
          <title>B</title>
          <item identifier="3" isvisible="false">
             <title>C</title>
          </item>
       </item>
       <item identifier="4" isvisible="false">
          <title>D</title>
       </item>
    </item>
    <item identifier="5" isvisible="false">
       <title>E</title>
    </item>
| A B

# 5. Validation

The XML 1.0 Specification from the W3C allows for two types of parsers: validating and non-validating. Non-validating parsers are only concerned with the well-formedness of a document-that is, ensuring that the syntactic rules of XML have been followed. Validating parsers, on the other hand, are required to implement the full XML 1.0 Specification. This means that validating parsers must follow all of the rules concerning structure, data types, and external references that are specified by a schema.

Schemas describe which elements may exist in a document and how those elements may be structured. The IMS Content Packaging specification provides limited guidance on the use of XML Schema Definition (XSD). While each of these schemas has different capabilities, any of these schemas can provide basic document validation. It is expected that any Manifest document in a Package that is written according to the IMS Content Packaging specification can be validated using the XSD schema available with this specification.

The IMS Content Packaging specification is accompanied by one XSD (imscp_v1p1.xsd). While it is technically feasible to validate documents that use DTDs, it is not possible to use a DTD to differentiate between two elements that use an element name in incompatible ways (for example IMS Meta-Data and IMS Content Packaging both use <resource> in meaningful, but incompatible ways, and IMS Content Packaging and IMS Question and Test both use <item> in meaningful, but incompatible ways). Rather than alter the IMS Content Packaging Information Model to adjust to the requirements of DTD validation, the Content Working Group made a decision to be forward-looking, towards XML Schemas, with respect to validation.

## 5.1 W3C Schema Validation

IMS has updated the Content Packaging Schema to support the Final Recommendation of the W3C XML Schema specification (dated) 2 May 2001. Currently, several commercial tools support Schema validation including: Xerces, XML Authority, XML Spy, and Oracle parsers.

The 'xml:' namespaced attributes are defined in file 'http://www.w3.org/2001/xml.xsd'. This is the reference to be used for on-line validation or a copy of this file must be placed in the root of the content package for local validation. Note that the file 'http://www.w3.org/2001/xml.xsd' is always the most up to date version of the file 'http://www.w3.org/2001/03/xml.xsd' as maintained by W3C.

# 6. Conformance

Conformance to a packaging specification is an important issue for stakeholders involved with the IMS Content Packaging specification. Conformance clarifies content interoperability. It sets an expectation for content vendors and their customers about how that content will be repackaged, and possibly used by compliant LMSs, computing platforms supporting instructional content, and learning service providers as content moves about within systems, between systems, and across the Web. It also helps LMS vendors, computing platforms, and learning services to control the scope of their data stores and tools or sub-systems required to operate on content Packages.

This specification addresses two levels of conformance to guide content developers in how LMS vendors, computing platforms, or learning services may deal with the elements and extensions content developers place within an IMS Manifest file. These same levels of conformance should guide those who repackage content for redistribution within their systems, across systems, or across the Web.

## 6.1 Package Conformance

For the purposes of conformance, an IMS Content Package is the relevant imsmanifest.xml file and all resources directly or indirectly referenced by this document (also known as the Package Interchange File).

### 6.1.1 Package Conformance Level 0 (no extensions)

1. The Package must contain a file called imsmanifest.xml in the root of the distribution medium (archive file, CD-ROM, etc.);
2. The Package must contain any directly referenced controlling files used DTD, XSD) in the root of the distribution medium (archive file, CD-ROM, etc.);
3. The imsmanifest.xml file must contain well-formed XML that adheres to the XML format described in section 3 of the IMS Content Packaging XML Binding specification;
4. If the imsmanifest.xml file contains IMS Meta-Data, it must contain a namespace extension to include meta-data according to the IMS Meta-Data Specification v1.2.1;
5. The imsmanifest.xml file must not reference any elements using XInclude. (This requirement may be relaxed when it is generally supported in XML parsers);
6. All files that a local resource (i.e., a resource that is contained entirely within the Package Interchange File) is dependent on must be identified by <file> elements in the <resources> section of the imsmanifest.xml file and must be contained within the directory or sub-directories that contain imsmanifest.xml.

### 6.1.2 Package Conformance Level 1 (utilizes extensions)

1. All level 0 conformance requirements (except 'e') apply;
2. The imsmanifest.xml file may contain additional namespace extensions. If additional namespace extensions are described and controlled using a schema or modified DTD, then any directly referenced control files must be included in the Package.

## 6.2 System and Tool Conformance

For the purposes of conformance, system and tool conformance refers to the systems and tools that import, export, create, and manipulate IMS Content Packages.

### 6.2.1 System and Tool Conformance Level 0 (may not preserve extensions)

1. A conforming system or tool must recognize and process any conforming IMS Content Package that conforms to level 0 or level 1. The features and functionality of systems and tools that process IMS Content Packages are purposely not specified;
2. All elements of the IMS Content Packaging XML Binding Specification v1.1.4 and IMS Meta-Data Specification v1.2.1 or the IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata that are present in imsmanifest.xml must be preserved upon re-transmittal;
3. Name-spaced extensions, other than the IMS Meta-Data Specification v1.2.1 namespace or the IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata namespace, may be ignored and may not be re-transmitted.

### 6.2.2 System and Tool Conformance Level 1 (preserves extensions)

1. Level 0 conformance requirements (a) and (b) apply;
2. All name-spaced extensions must be preserved upon re-transmittal.

## 6.3 Best Practice Recommendations for IMS Package Conformance Levels

This section contains additional recommendations to support the functionality and interoperability of IMS Content Packages.

- A general recommendation to all who create, deliver, or repackage content is that they publish at their public Websites which level of the IMS Content Package Conformance Level or System and Tool Conformance Levels they support. An organization or enterprise that originates a namespace extension is encouraged to make public the DTD or XSD files that define it;
- It is expected that content producers will organize their content for expected aggregations or disaggregation. That is, if content producers do not expect, or desire their content to be disaggregated, it should be encoded in a monolithic manifest. Conversely, sub-Manifests should be used to organize content according to expected levels of aggregation and disaggregation;
- The IMS Content Working Group expects that vendors of training systems, platforms, and learning spaces will actively use namespaced elements that are relevant to their product(s) or the training communities they serve. Additionally, content creators may want to use proprietary namespaces to support a richer set of features in their content than would otherwise be available, and negotiate support for those features with vendors of training systems, platforms, and learning spaces. Hence, the IMS Content Working Group strongly encourages systems and tools to recreate an originating IMS Manifest file's use of third party namespaces and namespaced elements when such content is repackaged for transmission from their system or tool to elsewhere on the Web;
- Content re-packagers should be guided by an original Package's use of sub-Manifests or references to external manifests when aggregating or disaggregating content. That is, a portion of a course or curriculum that is a candidate for aggregation or disaggregation will be held in a sub-Manifest. So, a system or tool should preserve the original sub-Manifest(s) or externally referenced manifests or, be able to replicate them when repackaging content to export out of their environment. It is expected that there will be no additions or deletions to elements and attributes within a sub-Manifest or externally referenced manifest.

# 7. Extensibility

To allow developers the most flexibility possible, the XML binding of a manifest may be freely extended. All elements that serve as containers for other elements may be extended to include new elements. Elements that contain data types (e.g., string, integer) and elements with a 'closed' data model may not be extended. Examples of elements with a closed data model include <schema> and <schemaversion>. Extensions must provide references (e.g., via namespacing) to the source of the extensions.

There are at least two cases where extensions can cause problems for developers. The first case is when interoperability with other content packaging tools and vendors is required. Custom extensions must then be agreed upon between individual parties making global interoperability very difficult. The second case is when a developer wishes to add extensions and also provide or alter a schema that will allow document validation. Each schema DTD or XSD) requires a different approach to handle extensions that can be validated. The following sections provide some brief explanations of approaches that may be used for handling extensions.

Note: The following examples consist of XML fragments to illustrate basic concepts of extensibility. These samples are not well formed and are missing some information such as any references to a control document (DTD or XSD). Complete sample files with their associated schemas can be found at http://www.imsglobal.org/content/packaging/.

## 7.1 Extending <metadata>

A content publisher or LMS vendor may need to transport or store meta-data that is not defined by the IMS Meta-Data Specification v1.2.1 [MD, 901].

For example, assume the fictitious LMS 'LitWare Inc.,' needs to maintain meta-data about the Instructional Design methodology used to create a course. The following steps illustrate how easily this can be done when using a schema based upon XML Schema Definition Language:

1. Create an XML schema that defines the new element(s). For the given example, the XML schema could consist of the following:

    <xsd:schema targetNamespace="http://www.litwareinc.net/xsd/litware"
       xmlns:xml="http://www.w3c.org/XML/1998/namespace"
       xmlns:xsd="http://www.w3c.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
       xmlns="http://www.litwareinc.org/xsd/litware"
       elementFormDefault="qualified">
    <xsd:element name="instructionaldesignmethodology" type="xsd:string"/>
    </xsd:schema>

1. When exporting to the learning management system, the element would appear as follows in imsmanifest.xml. The following sample shows a way to extend the IMS Meta-Data v1.2 [MD, 501]:

    <manifest identifier=MANIFEST1>
       <metadata>
          <schema>IMS Content</schema>
          <schemaversion>1.1</schemaversion>
          <imsmd:lom>
             <imsmd:general>
                <imsmd:title>
                   <imsmd:langstring xml:lang=en_US>Sample Manifest</imsmd:langstring>
                </imsmd:title>
                <imsmd:description>
                   <imsmd:langstring xml:lang=en_US>Metadata tensions</imsmd:langstring>
                </imsmd:description>
                <litware:instructionaldesignmethodology>LWI Mindmapping Methodology
                </litware:instructionaldesignmethodology>
             </imsmd:general>
          </imsmd:lom>
       </metadata>
       <organizations> . . .</organizations>
       <resources>. . .</resources>
    </manifest>

## 7.2 Extending <organizations>

It is expected that over time, many different approaches to content organization will emerge. The ADL has been developing one such approach in connection with its releases of SCORM versions. At the time of this specification release, the sample manifest, included with the Bindings and Examples from the Content Packaging website (http://www.imsglobal.org/content/packaging/) was a work in progress and may not be the final direction the ADL takes in future versions of SCORM. While some of the ideas expressed in this sample may not be complete and the file can not be properly validated, it still provides a good conceptual model of how the IMS Content Packaging specification allows different content organization schemes to essentially 'plug-in' to a Package Manifest file.

## 7.3 Extending <resources>

Extending <resources> using both external and in-line references is an important feature of Content Packaging. However, IMS is currently doing more testing and work in this area before providing samples of extending <resources> in this Best Practice Guide.

## 7.4 Extending with DTDs

In the examples above, the content models of the schemas must be 'open' to enable extensibility. To accomplish the same goal using the IMS Content Packaging DTD, a new DTD must be created to include the extensions. Such a DTD would differ from the IMS Content Packaging DTD. This approach would allow a document to be validated with extensions in it, but it limits the interoperability of the content Package.

# Appendix A - Supporting Files

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
\imscp_bestv1p1p4.pdf | IMS Content Packaging Best Practice Guide (this document)
\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.

# Appendix B - Additional Resources

## B1 - Various Documents

#### IMS Content Documents

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

IMS Content Packaging XML Binding:
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/

#### IMS General Reference

IMS Persistent, Location-Independent Resource Identifier Handbook:
http://www.imsglobal.org/implementationhandbook/imsrid_handv1p0.html

Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications:
http://www.imsglobal.org/implementationhandbook/

#### ADL

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

#### Internet Engineering Task Force (IETF)

RFC 2396: Uniform Resource Identifiers (URI): http://www.ietf.org/rfc/rfc2396.txt

#### IEEE

IEEE LTSC 1484.12 Learning Object Metadata: http://www.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 Recommendation of W3C: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

## B2 - Namespacing and Schema Reference

The namespaces, filenames, and namespace prefixes for XML instances using the XML Schema files are as follows:

Specification | Namespace | Filename | Prefix
--- | --- | --- | ---
Content Packaging | http://www.imsglobal.org/xsd/imscp_v1p1 | imscp_v1p1.xsd | imscp:
Meta-Data | http://www.imsglobal.org/xsd/imsmd_v1p2 | imsmd_v1p2.xsd | imsmd:
LIP | http://www.imsglobal.org/xsd/imslip_v1p0 | imslip_v1p0.xsd | imslip:
QTI | http://www.imsglobal.org/xsd/imsqti_v1p1 | imsqti_v1p1.xsd | imsqti:
Simple Sequencing | http://www.imsglobal.org/xsd/imsss_v1p0 | imsss_v1p0.xsd | imsss:
Learning Design | http://www.imsglobal.org/xsd/imsld_v1p0 | imsld_v1p0.xsd | imsld:

All of the samples provided with this specification, as listed in Appendix A, make use of the schema XSD) files located on the IMS website. The specification editors used XML Spy v5.1 and Turbo XML v2.3.1 to validate each of the samples listed in Appendix A, against the XSD files on the IMS website. It is expected that other XML Schema-capable parsers will also validate sample files as long as the parser is able to locate the online XML Schema files. It is best practice to use the online Schema file references (see Online XSD Files example below) as the XSD files on the IMS website will be the most up-to-date. Using the online XSD files requires the parser to have an open, functional connection to the Internet. If, however, an Internet connection is not available or users wish to validate files locally, they will need to change the namespace declarations in their samples to match the Local XSD Files example below.

#### Online XSD Files

For those XML instances using the XSD files as located on the IMS website, the declaration in the root <manifest> element is of the form:

    <manifest xmlns=http://www.imsglobal.org/xsd/imscp_v1p1
       xmlns:imsmd=http://www.imsglobal.org/xsd/imsmd_v1p2
       xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
       xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1
                       http://www.imsglobal.org/xsd/imscp_v1p1.xsd
                       http://www.imsglobal.org/xsd/imsmd_v1p2
                       http://www.imsglobal.org/xsd/imsmd_v1p2.xsd"
       identifier="Manifest01" version="IMS  CP  1.1.4">

#### Local XSD Files

For XML instances in which the XSD files are locally available, in the same directory as the instance, the declaration in the root <manifest> element is of the form:

    <manifest xmlns="http://www.imsglobal.org/xsd/imscp_v1p1"
       xmlns:imsmd="http://www.imsglobal.org/xsd/imsmd_v1p2"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1.xsd
                         imscp_v1p1.xsd
                         http://www.imsglobal.org/xsd/imsmd_v1p2
                         imsmd_v1p2.xsd"
       identifier="Manifest01" version="IMS  CP 1.1.4">

The 'version' attribute is optional.

# Appendix C - Harmonization

Harmonization between IMS specifications is important and IMS is committed to ensuring its specifications use similar strategies for vocabularies, GUIDs, element names, and others across all standards. For information about harmonization or sample implementations of the IMS Content Packaging specification and other IMS specifications, see the following:

- Using IMS Content Packaging to Package Instances of LIP and other IMS specifications. A general implementation handbook illustrating how to package instances of LIP that could also be applied to packaging instances of Meta-Data, QTI, or Enterprise. To download this document, visit the Implementation Handbook portion of the IMS website: http://www.imsglobal.org/implementationhandbook/.

# Appendix D - Possible Future Directions

This section describes open issues that the Content Packaging Working Group consider as recommendations for future version releases.

Table D1 List of issues to be resolved in the future.

Issue Identifier | Comment
--- | ---
CP113-49 | Using URNs as identifiers or use PLIDs instead of xs:ID.
CP113-51 | Clarification on the usage of the 'isvisible' attribute.
CP113-55 | [identifierref] needs to be made more solid and clearly defined.
CP113-56 | Common semantic interpretation of sub-Manifests.
CP113-62 | Externalizing sub-Mmanifests.
CP113-63 | Provide optional presentation hints.
CP113-64 | Creating an RDF version of the spec.
CP113-65 | Language for Title.
CP113-66 | Ambiguity in boolean values in binding.
CP113-68 | ADL 'location' extension for the 'meta-data' element.
CP113-80 | Lack of clarity in package scope in BPG.
CP113-110 | Adding "variation" element.
CP113-161 | Extra files in manifest.

# Appendix E - Glossary of Terms

## E1 - General Terms

ADL | Advanced Distributed Learning Initiative was started by the United States White House in 1997, and aims to advance the use of online training.
AICC | Aviation Industry CBT Committee is a membership-based international forum that develops recommendations on interoperable learning technologies for the aviation industry.
character set | The characters used by a computer to display information.
choice | One of the possible responses that a test taker might select. Choices contain the correct answers and distracters.
conformance statement | A conformance statement provides a mechanism for customers to fairly compare vendors of assessment tools and content.
database | A collection of information/data, often organized within tables, within a computer's mass storage system.Databases are structured in a way to provide for rapid search and retrieval by computer software. The following databases are used by testing systems: item, test definition, scheduling, and results.
DTD | Document Type Definition.
dynamic sequencing | The sequencing of items or sections is based upon previous responses from a test taker.
element | An XML term that defines a component within an XML document that has been identified in a way a computer can understand.
element contents | An XML term used to describe the content of the element.
element attributes | Provides additional information about an element.
IEEE | Institute of Electrical and Electronics Engineers that provides a forum for developing specifications and standards.
IMS | An organization dedicated to developing specification for distributed learning.
LTSC | Learning Technology Standards Committee
LMS | Learning Management System which is the system responsible for the management of the learning experience.
Meta-data | Meta-data: Descriptive information about data. Can be thought of as data about data. IMS specifications typically use meta-data to describe learning resources.
W3C | World Wide Web Consortium
XML | Extensible Mark-up Language is a specification, produced by the W3C.
XSD | XML Schema Definition

## E2 - Content Packaging Elements and Attributes

default | Indicates which organization scheme is the default one.
dependency | Identifies the location of a resource that contains dependent files.
file | A reference to a file that a resource is dependent on.
href | A reference to a URL.
identifier | An identifier that is unique within the manifest.
identifierref | A reference to an identifier in the manifest or in a resource.
isvisible | Indicates whether or not an item is displayed when the package is displayed or rendered.
item | A node within the organization.
manifest | A reusable unit of instruction. Encapsulates meta-data, organizations, and resource references.
metadata | Meta-data describing the manifest.
organization | Defines a particular hierarchical organization.
organizations | Describes one or more structures, or organizations for this package.
parameters | Static parameters to be passed to the resource at launch time.
resource | A reference to a resource.
resources | A collection of references to resources. There is no assumption of order or hierarchy.
schema | Describes the schema that defines and controls the manifest.
schemaversion | Describes version of the above schema (e.g., 1,0, 1.1).
title | Title of the organization.
type | Indicates the type of resource.
version | Identifies the version of this manifest (e.g., 1.0).
xml base | Provides a relative path offset for relative URIs in the package.

# About This Document

Title | IMS Content Packaging Best Practice and Implementation Guide
Editors | Colin Smythe (IMS), Alex Jackl (IMS)
Version | 1.1.4
Version Date | 04 October 2004
Status | Final Specification
Summary | This document describes the Best Practice and Implementation Guide of the Content Packaging specification.
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_bestv1p1p4.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.
Kerry 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) Rewrote section 7 on Extensibility to provide a more positive outlook. Moved the note to the end of the section and made minor wording changes; b) Carefully reviewed section 6 regarding conformance and split it between package and tool conformance. Dealt with local file references. Struck conformance level extension note. Deferred comments on property rights to global IMS guidance; c) Removed section 8 about open issues. Does not belong in the specification; d) Added wording to section 4.8.1 about GUIDs consistent with the note in the Information Model; e) Made sure references to DTD (Section 5.1 for example) match the documents and document names provided; f) Added Appendix A explaining which files accompany the specification (samples, DTDs, schemas, etc.); g) Rewrote section 5.1 to explain use of combined DTDs.
Final 1.1 | 19 April 2001 | Updated document to address the following open issues: a) Clarified the use of the <organization> and <item> elements in section 4.4; b) Moved reference to the xml:base function from section 4.5 <resources> Element to its own section in 4.8.3; c) Deprecated the use of XInclude: removed conformance statement in Section 6.1.3; removed sample in Section 7.3, added note to Section 4.8.2 that XInclude is a likely candidate for future use; created a new appendix called Appendix D Possible Future Directions; moved samples in 4.6.2 and 7.2 to new appendix; d) Modified the language in Section 5.2 regarding W3C schema validation; e) Added Appendix B2 Namespacing Reference; f) Addressed harmonization issues: removed QTI sample in Section 7.3, added Appendix C Harmonization; g) Added statement of recommendation to use PKZip v2.04g as the default Package Interchange File format in Section 4; h) Extended meta-data functionality to <organization>, <item>, and <file>; i) Changed the 'type' attribute on <organization> to 'structure' with a default value of 'hierarchical'; j) Updated Figure 3.1 illustrating the IMS Content framework. k) Added xml:base samples to section 4.8.3; l) Deprecated the use of <manifestref> and moved (sub)Manifests out of the <resources> block; m) Changed resource <item> element attribute back to 'identifieref' from 'resourceref'; n) Made several minor edits; changed references to sub-manifest to (sub)Manifest; updated the graphics and samples; o) Added <dependency> example to Section 4.5.
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 changes to clarify certain issues, including: a) Using multiple <organization> elements and choosing between them; b) Updating references to IMS Meta-Data v1.2 specification; c) Removed full samples for ease of updating in the future (samples are still available for download from the website).
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 | The changes contained within v1.1.4 are: a) Made several clarifying and updating editorial changes; b) Resolved inconsistent name-spacing using xml:lang and x:lang; c ) Clarified the order of elements in the manifest; d) Corrected "isvisible" nomenclature; e) Removed remaining references to <variation> element; f) Clarified the length of the string contained in the 'href' attribute; g) Clarified the usage of external meta-data; h) Clarified the placing and scope of meta-data; i) Documented how 'xml:base' should be used in sub-manifests; j) Documented "other files" issue in a manifest; k) Altered the "physical file" references to "content" or "file resources".

# Index

A
Aggregation 1, 2, 3, 4, 5, 6, 7
Attributes
default 1
isvisible 1
parameters 1
structure 1
type 1, 2
version 1
xml

base 1

B
Behavior 1
Best Practice Guide 1, 2, 3, 4, 5
Binding 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

C
Catalog 1
Conformance 1, 2, 3, 4
Content Package 1, 2
Course
content 1

D
Disaggregation 1, 2, 3, 4, 5, 6
DTD 1

E
Elements
dependency 1
file 1, 2
item 1
manifest 1, 2
organization 1, 2
resource 1
resources 1
schema 1, 2
title 1
Extensibility 1, 2
Extension 1, 2, 3, 4, 5

H
Harmonization 1

I
IEEE 1, 2, 3, 4, 5, 6, 7
IMS Specifications
Content Packaging 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
Learner Information Package 1, 2, 3, 4
Meta-Data 1, 2, 3, 4, 5, 6, 7
Question and Test Interoperability 1, 2, 3, 4, 5
imsmanifest 1, 2, 3, 4, 5, 6, 7, 8, 9
Information Model 1, 2, 3, 4, 5, 6
Interoperability 1, 2, 3, 4, 5
ISO 1
isvisible 1, 2, 3, 4, 5, 6

L
Learning 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Libraries 1
LMS 1, 2, 3, 4, 5, 6, 7, 8
LOM 1, 2
LTSC 1, 2, 3

M
Manifest 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
Meta-data 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

N
Namespace 1, 2, 3, 4, 5, 6
Namespacing 1

P
Package 1
Package Interchange File 1, 2, 3, 4, 5, 6, 7
PKZip 1
Profile 1

R
Resource 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Resources 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
RFC 1, 2

S
Schema 1, 2, 3, 4, 5, 6, 7, 8, 9
SCORM 1, 2
Sequencing 1
Services 1
Standards 1, 2
Structure 1, 2, 3, 4, 5, 6, 7, 8
sub-Manifest 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

U
URI 1, 2, 3

V
Validation 1, 2, 3, 4, 5
Vocabularies 1
Vocabulary 1

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

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

Z
ZIP 1
Zip 1, 2

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Content Packaging Best Practice and Implementation Guide ("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 Best Practice and Implementation Guide Revision: 04 October 2004