1EdTech Content Packaging Best Practice and Implementation Guide Version 1.1.4 Final Specification

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

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

Copyright © 2004 1EdTech Consortium. All Rights Reserved.

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

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

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

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

Table of Contents

1. Introduction
1.1 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 1EdTech 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 1EdTech 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 1EdTech 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.

1.2 Scope and Context

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

• 1EdTech Content Packaging Information Model v1.1.4 [CP, 04a];
• 1EdTech 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:

1.4 Nomenclature

1.5 References

2. Stakeholders

There are a number of stakeholders who are contributing to and stand to benefit from an 1EdTech Content Packaging specification derived from the 1EdTech 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 1EdTech 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 1EdTech Content Packaging specification is complemented by the overall goals of the 1EdTech 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:

• 1EdTech API draft specification version 0.6 (6/98);
• 1EdTech 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 1EdTech 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.

The complete, identified scope of the 1EdTech 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 1EdTech Content Packaging portion of the 1EdTech 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 1EdTech Content Packaging specification are focused on the scope represented in Figure 3.2.

3.2 Data Model

A future version of an 1EdTech Content specification will address important, core issues of a general and extendable content data model. The data model represents that portion of the 1EdTech 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 1EdTech Content specification will also take into account how the 1EdTech 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 1EdTech Content framework.

3.3 Run Time Environment

A future 1EdTech Content specification will deal also with the issues surrounding run time environments. The run time environment portion of the 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Packaging specification must contain an 1EdTech Manifest file. To ensure that the 1EdTech 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 1EdTech Package and cannot be processed. It is required that the name be kept, as above, in all lowercase letters.

The 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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="1EdTech CP 1.1.4">

   <metadata>
      <schema>1EdTech Content</schema>
      <schemaversion>1.1</schemaversion>
      <imsmd:lom>
         <imsmd:general>
            <imsmd:title>
               <imsmd:langstring xml:lang="en_US">1EdTech 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>1EdTech Content</schema>
      <schemaversion>1.1</schemaversion>
      <imsmd:lom>
         <imsmd:general>
            <imsmd:title>
               <imsmd:langstring xml:lang="en_US">1EdTech 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.

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.

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

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

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

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

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

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

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 1EdTech 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 1EdTech Content Packaging specification can be validated using the XSD schema available with this specification.

The 1EdTech 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 1EdTech Meta-Data and 1EdTech Content Packaging both use <resource> in meaningful, but incompatible ways, and 1EdTech Content Packaging and 1EdTech Question and Test both use <item> in meaningful, but incompatible ways). Rather than alter the 1EdTech 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

1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Packaging XML Binding specification;
4. If the imsmanifest.xml file contains 1EdTech Meta-Data, it must contain a namespace extension to include meta-data according to the 1EdTech 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 1EdTech 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 1EdTech Content Package that conforms to level 0 or level 1. The features and functionality of systems and tools that process 1EdTech Content Packages are purposely not specified;
2. All elements of the 1EdTech Content Packaging XML Binding Specification v1.1.4 and 1EdTech 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 1EdTech 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 1EdTech Package Conformance Levels

This section contains additional recommendations to support the functionality and interoperability of 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Working Group strongly encourages systems and tools to recreate an originating 1EdTech 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 1EdTech 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>

2. 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 1EdTech Meta-Data v1.2 [MD, 501]:

<manifest identifier=MANIFEST1>
   <metadata>
      <schema>1EdTech 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 1EdTech 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, 1EdTech 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 1EdTech Content Packaging DTD, a new DTD must be created to include the extensions. Such a DTD would differ from the 1EdTech 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 1EdTech Content Packaging specification documents and are available in the download .zip file (imscp_v1p1p4.zip). The files in the zip file are as follows:

Appendix B - Additional Resources

B1 - Various Documents

1EdTech Content Documents

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

1EdTech Content Packaging XML Binding:
http://www.imsglobal.org/content/packaging/

1EdTech Meta-Data Documents

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

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

1EdTech General Reference

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

Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech 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:

All of the samples provided with this specification, as listed in Appendix A, make use of the schema XSD) files located on the 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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="1EdTech  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="1EdTech  CP 1.1.4">

The 'version' attribute is optional.

Appendix C - Harmonization

Harmonization between 1EdTech specifications is important and 1EdTech 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 1EdTech Content Packaging specification and other 1EdTech specifications, see the following:

• Using 1EdTech Content Packaging to Package Instances of LIP and other 1EdTech 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 1EdTech 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.

Appendix E - Glossary of Terms

E1 - General Terms

E2 - Content Packaging Elements and Attributes

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History

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