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.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
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:
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.
This document is the IMS Content Packaging (CP) Best Practice and Implementation Guide. As such, it should be used in conjunction with:
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.
The structure of this document is:
||The relationship of
this specification to its stakeholders;
|3. Relationship to
||The relationship of
this specification activity to other IMS and external
|4. Conceptual Model
||A brief summary of the
Content Packaging Information Model;
||A discussion of the
usage of XSDs for validation;
||The expectations on
systems that claim conformance to the Content Packaging
||The ways in which
proprietary extensions are supported through this
|Appendix A -
||Files that accompany
the IMS Content Packaging specification that are available for
|Appendix B -
resources relevant to Content Packaging;
|Appendix C -
resources related to harmonization with other IMS
|Appendix D - Future
||List of future
|Appendix E - Glossary
||A glossary of the key
terms and elements used within the specification.
||Aviation Industry CBT
Electronic & Electrical Engineering
Object Reference Model
||World Wide Web
Packaging Information Model v1.1.4, C.Smythe,
A.Jackl, IMS Global Learning Consortium, Inc., October
Packaging XML Binding v1.1.4, C.Smythe,
A.Jackl, IMS Global Learning Consortium, Inc., October
Packaging Summary of Changes v1.1.4, C.Smythe,
A.Jackl, W.Kraan, IMS Global Learning Consortium, Inc.,
||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.
Location-Independent, Resource Identifier Implementation Handbook
v1.0, M.McKell, IMS Global Learning Consortium, Inc.,
||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.
Resource Meta-data v1.2.1, S.Thropp, M.McKell, IMS Global
Learning Consortium, Inc., September 2001.
Resource Meta-data v1.2, T.Anderson, M.McKell, IMS Global
Learning Consortium, Inc., May 2001.
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 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.
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:
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
The following sections describe these more fully.
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:
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.
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.
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.
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:
Software that processes a Content Package may use the above procedure or it may:
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:
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:
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.
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.
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.
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.
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.
'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>
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.
The following elements can be referenced using the identifierref attribute of an item:
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.
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.
|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>
<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>
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.
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.
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.
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).
For the purposes of conformance, system and tool conformance refers to the systems and tools that import, export, create, and manipulate IMS Content Packages.
This section contains additional recommendations to support the functionality and interoperability of IMS Content Packages.
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/.
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:
<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>
<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>
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.
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.
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.
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:
||IMS Content Packaging
||IMS Content Packaging
||IMS Content Packaging
Best Practice Guide (this document)
||IMS Content Packaging
Summary of Changes
||IMS Content XML
Schema, version 1.1.4
||Illustrates a simple
manifest using Content Packaging elements.
||Illustrates a simple
manifest packaging QTI elements.
||Illustrates a manifest
that uses all elements and attributes defined in the IMS Content
||Illustrates the use of
multiple <organizations>, to provide different paths
through a course.
||Illustrates a simple
||Illustrates the use of
sub-Manifests to promote reuse. This example takes the Simple
Manifest example, and implements it using sub-Manifests.
Content Packaging Information Model:
Content Packaging XML Binding:
Meta-Data Best Practice and Implementation Guide:
Learning Resource Meta-Data Information Model:
Persistent, Location-Independent Resource Identifier
Content Packaging to Package Instances of LIP and Other IMS
Sharable Content Object Reference Model: http://www.adlnet.org/
RFC 2396: Uniform Resource Identifiers (URI): http://www.ietf.org/rfc/rfc2396.txt
IEEE LTSC 1484.12 Learning Object Metadata: http://www.ltsc.ieee.org/wg12/
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/
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 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.
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">
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.
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:
This section describes open issues that the Content Packaging Working Group consider as recommendations for future version releases.
||Using URNs as
identifiers or use PLIDs instead of xs:ID.
||Clarification on the
usage of the 'isvisible' attribute.
to be made more solid and clearly defined.
interpretation of sub-Manifests.
||Creating an RDF
version of the spec.
||Ambiguity in boolean
values in binding.
extension for the 'meta-data' element.
||Lack of clarity in
package scope in BPG.
||Extra files in
Learning Initiative was started by the United States White House
in 1997, and aims to advance the use of online training.
||Aviation Industry CBT
Committee is a membership-based international forum that develops
recommendations on interoperable learning technologies for the
||The characters used by
a computer to display information.
||One of the possible
responses that a test taker might select. Choices contain the
correct answers and distracters.
statement provides a mechanism for customers to fairly compare
vendors of assessment tools and content.
||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.
||The sequencing of
items or sections is based upon previous responses from a test
||An XML term that
defines a component within an XML document that has been
identified in a way a computer can understand.
||An XML term used to
describe the content of the element.
information about an element.
Electrical and Electronics Engineers that provides a forum for
developing specifications and standards.
dedicated to developing specification for distributed
System which is the system responsible for the management of the
information about data. Can be thought of as data about
data. IMS specifications typically use meta-data to
describe learning resources.
||World Wide Web
Language is a specification, produced by the W3C.
organization scheme is the default one.
location of a resource that contains dependent files.
||A reference to a file
that a resource is dependent on.
||A reference to a
||An identifier that is
unique within the manifest.
||A reference to an
identifier in the manifest or in a resource.
||Indicates whether or
not an item is displayed when the package is displayed or
||A node within the
||A reusable unit of
instruction. Encapsulates meta-data, organizations, and resource
||Defines a particular
||Describes one or more
structures, or organizations for this package.
||Static parameters to
be passed to the resource at launch time.
||A reference to a
||A collection of
references to resources. There is no assumption of order or
||Describes the schema
that defines and controls the manifest.
||Describes version of
the above schema (e.g., 1,0, 1.1).
||Title of the
||Indicates the type of
||Identifies the version
of this manifest (e.g., 1.0).
||Provides a relative
path offset for relative URIs in the package.
||IMS Content Packaging
Best Practice and Implementation Guide
||Colin Smythe (IMS),
Alex Jackl (IMS)
||04 October 2004
describes the Best Practice and Implementation Guide of the
Content Packaging specification.
||04 October 2004
||This document has been
approved by the IMS Technical Board and is made available for
|To register any
comments or questions about this specification please visit:
The following individuals contributed to the development of this document:
|Version No.||Release Date||Comments|
||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.
||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.
||23 May 2001
sample in Binding Appendix B.
||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).
||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;
||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".
Aggregation 1, 2, 3, 4, 5, 6, 7
type 1, 2
Best Practice Guide 1, 2, 3, 4, 5
Binding 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Conformance 1, 2, 3, 4
Content Package 1, 2
Disaggregation 1, 2, 3, 4, 5, 6
file 1, 2
manifest 1, 2
organization 1, 2
schema 1, 2
Extensibility 1, 2
Extension 1, 2, 3, 4, 5
IEEE 1, 2, 3, 4, 5, 6, 7
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
isvisible 1, 2, 3, 4, 5, 6
Learning 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
LMS 1, 2, 3, 4, 5, 6, 7, 8
LOM 1, 2
LTSC 1, 2, 3
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
Namespace 1, 2, 3, 4, 5, 6
Package Interchange File 1, 2, 3, 4, 5, 6, 7
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
Schema 1, 2, 3, 4, 5, 6, 7, 8, 9
SCORM 1, 2
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
URI 1, 2, 3
Validation 1, 2, 3, 4, 5
W3C 1, 2, 3, 4, 5, 6, 7, 8
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
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