IMS Logo

IMS Content Packaging Information Model

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 Information Model
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.


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. IMS Content Packaging Conceptual Model
     2.1 Key Elements
     2.2 Standard Name for the Manifest File

3. Extensibility

4. Manifest Elements
     4.1 sub-Manifests
     4.2 Href URL Construction Algorithm

About This Document
     List of Contributors

Revision History

Index

1. Introduction

1.1 Overview

The IMS Content Packaging (CP) Information Model describes data structures that are used to provide interoperability of Internet based content with content creation tools, learning management systems (LMS), and run time environments. The objective of the IMS CP Information Model is to define a standardized set of structures that can be used to exchange content. These structures provide the basis for standardized data bindings that allow software developers and implementers to create instructional materials that interoperate across authoring tools, LMSs, and run time environments that have been developed independently by various software developers.

Note: The scope of the IMS CP specification is focused on defining interoperability between systems that wish to import, export, aggregate, and disaggregate Packages of content. Future documents comprising the IMS Content specification will address requirements regarding content data models and communication between run time environments and LMSs.

1.2 Scope and Context

This document is the IMS CP Information Model specification. As such it will be used as the basis for the production of the following documents:

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

Information on possible future development of the Content Packaging specification can be found in Appendix D of the Best Practices Guide [CP,04c].

1.3 Structure of this Document

The structure of the rest of this document is:

2. IMS Content Packaging Conceptual Model
The underlying usage, processing control and data structures comprising Content Packaging;
3. Extensibility
The ways in which proprietary extensions are supported through this specification;
4. Manifest Elements
The detailed description of the Manifest elements in terms of their properties and attributes.

1.4 Nomenclature

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

1.5 References

[CP, 04b]
IMS Content Packaging XML Binding v1.1.4, C.Smythe, A.Jackl, IMS Global Learning Consortium, Inc., October 2004.
[CP, 04c]
IMS Content Packaging Best Practice and Implementation Guide v1.1.4, C.Smythe, A.Jackl, IMS Global Learning Consortium, Inc., October 2004.
[CP, 04d]
IMS Content Packaging Summary of Changes v1.1.4, C.Smythe, A.Jackl, IMS Global Learning Consortium, Inc., October 2004.
[MD, 04]
IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata v1.3, P.Barker, L.Campbell, A.Roberts, IMS Global Learning Consortium, Inc., May 2004.
[ISO/IEC10646]
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).

2. IMS Content Packaging Conceptual Model

Figure 2.1 is a conceptual diagram that illustrates the components of the IMS Content Packaging Information Model. As indicated in the IMS Content Packaging Best Practice Guide, this is part of the larger IMS Content Framework, which forms the basis for this and future specifications.

IMS Content Packaging scope
Figure 2.1 - IMS Content Packaging scope.

2.1 Key Elements

The IMS Package depicted in Figure 2.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 required 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 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.

2.2 Standard Name for the Manifest File

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

imsmanifest.xml

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

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

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

3. Extensibility

An important underpinning of the IMS Content Packaging specification is rich support for extensibility.

While the base Content Packaging Information Model leverages the rich set of meta-data elements defined in the IMS Meta-Data Specification v1.2.1 or the IEEE 1484.12.3 Standard for eXtensible Markup Language (XML) Schema Binding for Learning Object Metadata (see IMS Meta-Data v1.3 [MD, 04] for best practices and guidelines in implementing the IEEE LOM specification), it defines only the basic structures for organization and resources (Web Content).

It is expected that implementers of this specification will define new types of resources and organizations to describe and transport rich learning resources, and over time, it may be possible to incorporate widely used extensions into future versions of this specification.

4. Manifest Elements

This section provides a conceptual, informative description of the elements contained in a Manifest. Figure 4.1 illustrates the primary elements of a Manifest.

Manifest elements
Figure 4.1 - Manifest elements.

Table 4.1 provides a conceptual, informative description of the data objects. The columns used in the table refer to:

No:
The number of the data element. An element may be composed of sub-elements. The numbering scheme reflects these relationships.
Name:
The descriptive name of the element.
Explanation:
A brief functional description of the element.
Reqd:
Indicates if the element is required.


M = mandatory element that must be included in the data object, if the element at the higher level is included.


C = conditional element, existence is dependent on values of other elements.


O = optional element.
Mult:
Multiplicity of the element. Repeatability of an Element implies that all sub-elements repeat with the Element.


Blank (-) = single instance.


Number = maximum number of times the element is repeatable.


n = multiple occurrences allowed, no limit.
Type:
A description of formatting rules for the data element: Type includes the maximum length of the element. The international character set specified by ISO 10646 will be used for all fields.


Container = 'tag' element, of fixed length.


ID = element used to uniquely identify an object.


IDRef = a reference to an ID.


String (n) = descriptive element (smallest permitted maximum).


Boolean = True | False.

Notes: Additional descriptive information about the element.

  1. In the table below, the Manifest elements contained in the Content Packaging Information Model are described using mixed case to enhance readability. Implementers of this specification should refer to particular binding specifications. For example, some XML bindings follow the W3C convention of using lowercase for all elements;
  2. Elements surrounded by braces ({}) indicate areas in the Information Model where elements from other information models or specifications are expected to be included;
  3. The order of elements described in Table 4.1 is not significant from the perspective of the information model. However, the corresponding XML binding imposes this implied order as a requirement for IMS manifests.
Table 4.1 - Content packaging data objects.

No Name Explanation Reqd Mult Type Note
1
Manifest
A reusable unit of instruction. Encapsulates meta-data, organizations, and resource references.
M
-
Container


1.1
Identifier
An identifier that is unique within the Manifest.
M
-
ID
See the Best Practice Guide for guidelines on the use of identifiers.
1.2
Version
Identifies the version of this Manifest (e.g., 1.0).
O
-
String (20)
Used to identify if there have been any changes to the Package. Identifier is the same in two Manifest files.
1.3
Xml:base
Provides the relative path offset for the content file(s).
O
-
String (2000)
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
1.4
Meta-data
Meta-data describing the Manifest.
O
-
Container

1.4.1
Schema
Describes the schema that defines and controls the Manifest.
O
-
String (100)
If no schema element is present, it is assumed to be "IMS Content".
1.4.2
SchemaVersion
Describes the version of the above schema (e.g., 1,0, 1.1).
O
-
String (20)
If no version is present, it is assumed to be "1.1"
1.4.3
{Meta-Data}
This is where Meta-data is inserted using an appropriate information model.
O
n
-
By default, the information contained in this section is defined by the IMS Meta-Data specification.
1.5
Organizations
Describes one or more structures or organizations for this package.
M
-
Container
An organization can be selected by its meta-data.
1.5.1
Default
Indicates which organization scheme is the default one.
O
-
IDRef
When used, this must point to a direct child <organization> in the manifest i.e., it cannot point to an <organization> in a sub-manifest. If not supplied, the first organization element encountered is assumed to be the default.
1.5.2
Organization
Describes a particular hierarchical organization.
O
n
Container
Different views or organizational paths through the content can be described using multiple instances of organization.
1.5.2.1
Identifier
An identifier, for the organization, that is unique within the Manifest file.
M
-
ID
See the Best Practice Guide for guidelines on the use of identifiers.
1.5.2.2
Structure
Has a default value of "hierarchical" for describing the shape of an organization.
O
-
String
(200)
Other values for structure will likely become part of a future specification.
1.5.2.3
Title
Describes the title of the organization.
O
-
String (200)
Used to help user decide which organization to choose.
1.5.2.4
Item
A node that describes the shape of the organization.
M
n
Container
Can be used in a hierarchical organizational scheme by ordering and nesting.
1.5.2.4.1
Identifier
An identifier, for the Item, that is unique within the Manifest file.
M
-
ID
See the Best Practice Guide for guidelines on the use of identifiers.
1.5.2.4.2
IdentifierRef
A reference to an identifier in the resources section or a sub-Manifest.
O
-
String (2000)


1.5.2.4.3
Title
Title of the item.
O
-
String (200)


1.5.2.4.4
IsVisible
Indicates whether or not this item is displayed when the structure of the Package is displayed or rendered.
O
-
Boolean
If not present, value is assumed to be "true".
This value only affects the item for which it is defined and not the children of the Item or a resource associated with an Item.
1.5.2.4.5
Parameters
Static parameters to be passed to the resource at launch time.
O
-
String (1000)
#<parameter>
<name>=<value>(&<name>=<value>)*(#<parameter>)
?<name>=<value>(&<name>=<value>)*(#<parameter>)
 
Where <parameter> is some implementation defined characterstring value
Where <name> is some implementation defined name
Where <value> is some implementation defined value
The "=" is required to separate the <name> and <value> pair
The "&" is required to separate multiple sets of <name> and <value> pairs
The (&<name>=<value>)* indicates that the 0 or more <name> and <value> pairs can be concatenated together
 
NOTE:   The characters used in the parameters field may need to be URL encoded.  RFC 2396 defines the rules and requirements for encoding URLs. 
1.5.2.4.6
Item
A sub-node within this organization.
O
n
Container
This is a sub-item and repeats all the parts of <item>.
1.5.2.4.7
Meta-data
Meta-data describing this item.
O
-
Container
See item 1.4.3 above
1.5.2.4.7.1
{Meta-Data}
This is where Meta-data is inserted using an appropriate information model.
O
n
-
By default, the information contained in this section is defined by the IMS Meta-Data specification.
1.5.2.4.8
Meta-data
Meta-data describing this organization.
O
-
Container
See item 1.4.3 above
1.5.2.4.8.1
{Meta-Data}
This is where Meta-data is inserted using an appropriate information model.
O
n
-
By default, the information contained in this section is defined by the IMS Meta-Data specification.
1.6
Resources
A collection of references to resources. There is no assumption of order or hierarchy.
M
-
Container


1.6.1
Xml:base
Provides the relative path offset for the content file(s).
O
-
String (2000)


1.6.2
Resource
A reference to a resource.
O
n
Container


1.6.2.1
Identifier
An identifier, of the resource, that is unique within the scope of its containing manifest file.
M
-
ID
See the Best Practice Guide for guidelines on the use of identifiers.
1.6.2.2
Type
Indicates the type of resource.
M
-
String (1000)
The only current types are:
- "webcontent", defined as content that can be hosted in or launched by an Internet browser (this includes HTML-based content, content that requires plug-ins e.g., Flash, Real Media and executables that are launched by a browser);
- The labels defined in Section 7 of the document 'Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications, Version 1.0 Implementation Handbook, August 2001'; Note that IMS specifications and versions of IMS specifications that had not yet been released at the time of writing of this document, should follow the syntax as specified in section 7.'
NOTE: An IMS specification may extend the table in section by using the syntax and including a normative statement to that effect in the specification;
- "imsldcontent" when the content is used to support the IMS Learning Design specification;
- "other", which should be used when no other term is appropriate.
1.6.2.3
Href
A reference to a URL.
O
-
String (2000)
If the URL is also based upon the contents of the 'parameter' attribute of the <item> referencing the <resource> then the algorithm defined in Section 4.2 should be used to construct the full URL. The syntax for the 'Href' value must conform to RFC2396.
1.6.2.4
Xml:base
Provides the relative path offset for the content file(s).
O
-
String (2000)
See item 1.3 above.
1.6.2.5
Meta-data
Meta-data describing this resource.
O
-
Container
See item 1.4.3 above
1.6.2.5.1
{Meta-Data}
This is where Meta-data is inserted using an appropriate information model.
O
n
-
By default, the information contained in this section is defined by the IMS Meta-Data specification.
1.6.2.6
File
A listing of files that this resource is dependent on.
O
-
Container
An element identifying a single file this resource is dependent on. Repeat as needed for each file for a given resource.
1.6.2.6.1
Href
Identifies the location of the file.
M
n
String (2000)
The syntax for the 'Href' value must conform to RFC2396.
1.6.2.6.2
Meta-data
Meta-data describing this file.
O
-
Container
See item 1.4.3 above.
1.6.2.6.2.1
{Meta-Data}
This is where Meta-data is inserted using an appropriate information model.
O
n
-
By default, the information contained in this section is defined by the IMS Meta-Data specification.
1.6.2.7
Dependency
Identifies a resource whose files this resource depends upon.
O
n
IDref
This element identifies a single resource which can act as a container for multiple files that this resource depends upon.
1.6.2.7.1
IdentifierRef
A reference to an identifier in the resources section.
M
-
String (2000)
This indentifierref cannot reference an identifier in a sub-manifest.
1.7
Manifest
A reusable unit of instruction. Encapsulates meta-data, organizations, and resource references.
O
n
Container
See section 4.1 sub-Manifests below for more information.

4.1 sub-Manifests

When the identifierref of an <item> in an <organization> references a sub-Manifest rather than another type of resource, this shall be interpreted as follows:

The diagram in Figure 4.2 explains how the content of a sub-Manifest is merged with the content of a referencing manifest in the rendering of a navigation tree. The circles represent items in an organization structure. In this example, the organization of the sub-manifest does not have a title attribute.

Merging <organization> from a (sub)Manifest
Figure 4.2 - Merging <organization> from a sub-Manifest.

The diagram in Figure 4.3 shows an example where the <organization> of the sub-Manifest does have a title attribute.

Merging an attributeless <organization> from a sub-Manifest
Figure 4.3 Merging an attributeless <organization> from a sub-Manifest.

In Figure 4.4, the diagram explains how the content of a sub-Manifest is merged with an item that has children of its own, and how the referencing item's children take precedence over those they merge with. In this example, the organization of the sub-Manifest does not have a title attribute.

Merging <organization> from a sub-Manifest when the referencing item has children
Figure 4.4 Merging <organization> from a sub-Manifest when the referencing item has children.

4.2 Href URL Construction Algorithm

In the cases where full URL referenced in the 'Href' value is also based upon the parameters passed in the 'parameter' attribute of the <item> referencing the <resource> then the following algorithm is to be used to construct the full URL:

While first char of parameters is in"?&"
   Clear first char of parameters
If first char of parameters is "#"
  If the URI contains "#"
      Discard parameters
   Else

      Append parameters to the URI
   Done processing URI
If the URI contains "?"
  Append "&" to the URI
Else

  Append "?" to the URI
Append parameters to the URI
Done processing the URI

The definition of this algorithm is normative.

About This Document

Title
IMS Content Packaging Information Model
Editors
Colin Smythe (IMS), Alex Jackl (IMS)
Version
1.1.4
Version Date
04 October 2004
Status
Final Specification
Summary
This document describes the Content Packaging Information Model, which is used to support content interoperability between different authors, publishers, and other corresponding content developers.
Revision Information
04 October 2004
Purpose
This document has been approved by the IMS Technical Board and is made available for adoption.
Document Location
http://www.imsglobal.org/content/packaging/cpv1p1p4/imscp_infov1p1p4.html

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

List of Contributors

The following individuals contributed to the development of this document:

Name Organization Name Organization
Thor Anderson
Collegis
Boyd Nielsen
NETg
Jay Beavers
Microsoft
Bill Olivier
CETIS
Fred Beshears
UC Berkeley
Claude Ostyn
Click2learn, Inc.
Kerry Blinco
DEST
Mike Pettit
Blackboard
Lorna Campbell
JISC (CETIS)
Daniel Rehak
Carnegie Mellon University
Adam Cooper
FD Learning
Tyde Richards
IBM
Rich Cushman
SCT
GianLuca Rolandelli
GIUNTI
Philip Dodds
ADL
Udo Schuermann
Blackboard
Pierre Gorissen
SURF
James Simon
SUN Microsystems
Steve Griffin
IMS
Colin Smythe
IMS
Mike Halm
Penn State
Colin Tattersall
OUNL
Andy Heath
IMS Europe
Schawn Thropp
ADL
Alan Hoberney
ADL
Tom Wason
IMS
Alex Jackl
IMS
Raymond Yee
UC Berkeley
Wilbert Kraan
JISC (CETIS)
Bill Young
Sun Microsystems
Mladen Maljkovic
WebCT
Kenny Young
Microsoft
Chris Moffatt
Microsoft




Revision History

Version No. Release Date Comments
Final 1.0
25 May 2000
Updated document to address the following open issues:
a) Added a definition to the table for element 3.2.2 with the name "webcontent";
b) Note #1 added about using mixed case to enhance table readability;
c) Added section 4.8.1 on identifiers;
d) Note #2 added as description about how element names within curly braces are really just section placeholders and not real elements.
Final 1.1
19 April 2001
Updated document to address the following open issues:
a) Clarified the use of the <organization> and <item> elements;
b) Added statement of recommendation to use PKZip v2.04g as the default Package Interchange File format in Section 1.2;
c) Extended meta-data functionality to <organization>, <item>, and <file>;
d) Changed the type attribute on <organization> to structure with a default value of hierarchical;
e) Changed the href attribute on the <resource> element from Mandatory to Optional;
f) Deprecated the use of <manifestref> and moved (sub)Manifests out of the <resources> block;
g) Changed resource <item> element attribute back to "identifierref" from "resourceref";
h) Made several minor edits; changed references to sub-manifest to (sub)Manifest; updated the graphics;
i) Changed Boolean type in the elements table from (0,1) to (true | false), in order to work with schemas.
Final 1.1.1
23 May 2001
Updated XML-Schema sample in Binding Appendix B.
Final 1.1.2
08 August 2001
Made several editorial corrections, and:
a) Updated references to IMS Meta-Data v1.2;
b) Added explanation and diagrams to clarify the use of (sub)Manifests;
c) Corrected the Manifest elements drawing.
Final 1.1.3
12 June 2003
The changes contained within v1.1.3 are:
a) 'xml:' prefix recommendation - adoption of the W3C 'xml.xsd' file for the definition of the 'xml:' namespaced attributes available to the content package;
b) XML binding version identification attribute - clarification on the version numbering and corresponding namespace consequences for the content package XML schema;
c) ID and IDREF usage in the XML binding - clarification on the implications of the usage of the 'xsd:ID' and 'xsd:IDREF' features in the content package XML schema;
d) XML binding min/max constraints relaxation - removal of the min/max constraints that are currently incorrectly imposed within the content package XML schema;
e) 'parameter' attribute vocabulary - adoption of a syntax for the definition of the parameters as contained in the 'parameter' attribute plus definition of the algorithm to construct an associated URI;
f) 'isvisible' attribute clarification - clarification on the consequences on the rendering of the content and its title due to the usage of the 'isVisible' attribute;
g) 'type' attribute vocabulary - clarification on the usage of the 'webcontent' and other terms permitted for the 'type' attribute vocabulary
h) 'Href' filename format recommendation - formal definition of the file name formats that must be adopted when using the 'Href' attribute;
i) ZIP file format recommendation - formal definition of the ZIP file format that must be adopted;
j) Submanifest usage best practices clarification - clarification on the permitted referencing between a manifest and its contained (sub)Manifests.
Final 1.1.4
04 October 2004
The changes contained within v1.1.4 are:
a) Several editorial and clarifying updates and changes;
b) Section 4.1 Notes updated to describe element ordering;
c) Parameter Construction Algorithm updated and documented;
d) Local and remote XSD validation issues clarified;
e) Sub-Manifest section clarified and updated;
f) Clarification on default attribute on the <organizations> element;
g) Sub-manifest referencing using the <dependency> element;
h) Replaced references to physical files with file resources.

Index

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

B
Behavior 1, 2
Best Practice Guide 1, 2, 3, 4, 5
Binding 1, 2, 3

C
Course
     content 1

D
Disaggregation 1

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

I
IEEE 1
IMS Specifications
     Content Packaging 1, 2, 3, 4, 5
     Learner Information Package 1
     Meta-Data 1, 2, 3, 4
imsmanifest 1, 2
Information Model 1, 2, 3, 4
Interoperability 1
ISO 1, 2

L
Learning 1, 2, 3
LMS 1, 2
LOM 1

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

N
Namespace 1
Normative 1, 2

P
Package 1
Package Interchange File 1, 2, 3
PKZip 1

R
Resource 1, 2, 3, 4, 5, 6, 7
Resources 1, 2, 3, 4, 5, 6, 7
RFC 1

S
Schema 1, 2
Structure 1, 2, 3
sub-Manifest 1, 2, 3, 4, 5, 6

U
URI 1

V
Validation 1, 2

W
W3C 1, 2, 3, 4

X
XML 1, 2, 3, 4, 5, 6, 7
     XSD 1, 2, 3, 4

Z
ZIP 1
Zip 1

 

 

 

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