IMS Logo

IMS Content Packaging Summary of Changes

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 Summary of Changes
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 Content Packaging Overview
1.2 Scope and Context
1.3 Structure of this Document
1.4 Nomenclature
1.5 References

2. Amendments and Errata Instructions
2.1 Namespacing of 'xml:lang'
2.1.1 Reference to CP Issues List
2.1.2 Information Model Changes
2.1.3 XML Binding Changes
2.1.4 Best Practice Changes
2.2 Conflicting Information on <organizations>
2.2.1 Reference to CP Issues List
2.2.2 Information Model Changes
2.2.3 XML Binding Changes
2.2.4 Best Practice Changes
2.3 Clarification on the Order of Elements in a Manifest
2.3.1 Reference to CP Issues List
2.3.2 Information Model Changes
2.3.3 XML Binding Changes
2.3.4 Best Practice Changes
2.4 Typographic Correction in Best Practice Guide
2.4.1 Reference to CP Issues List
2.4.2 Information Model Changes
2.4.3 XML Binding Changes
2.4.4 Best Practice Changes
2.5 Remove Reference to the <variation> Element
2.5.1 Reference to CP Issues List
2.5.2 Information Model Changes
2.5.3 XML Binding Changes
2.5.4 Best Practice Changes
2.6 Correction for Online Validation of the Examples
2.6.1 Reference to CP Issues List
2.6.2 Information Model Changes
2.6.3 XML Binding Changes
2.6.4 Best Practice Changes
2.7 Clarification on the Length of the 'href' Attribute String
2.7.1 Reference to CP Issues List
2.7.2 Information Model Changes
2.7.3 XML Binding Changes
2.7.4 Best Practice Changes
2.8 Clarification on the Usage of External Meta-data
2.8.1 Reference to CP Issues List
2.8.2 Information Model Changes
2.8.3 XML Binding Changes
2.8.4 Best Practice Changes
2.9 Scoping of Meta-data in a Content Package
2.9.1 Reference to CP Issues List
2.9.2 Information Model Changes
2.9.3 XML Binding Changes
2.9.4 Best Practice Changes
2.10 Correction of the Parameter Construction Algorithm
2.10.1 Reference to CP Issues List
2.10.2 Information Model Changes
2.10.3 XML Binding Changes
2.10.4 Best Practice Changes
2.11 Usage of Local and Remote XSDs for Instance Validation
2.11.1 Reference to CP Issues List
2.11.2 Information Model Changes
2.11.3 XML Binding Changes
2.11.4 Best Practice Changes
2.12 The Usage of 'xml:base' in Sub-manifests
2.12.1 Reference to CP Issues List
2.12.2 Information Model Changes
2.12.3 XML Binding Changes
2.12.4 Best Practice Changes
2.13 Improved Guidance on Merging Sub-manifests
2.13.1 Reference to CP Issues List
2.13.2 Information Model Changes
2.13.3 XML Binding Changes
2.13.4 Best Practice Changes
2.14 Clarification on the Default Attribute of the <organizations>
Element

2.14.1 Reference to CP Issues List
2.14.2 Information Model Changes
2.14.3 XML Binding Changes
2.14.4 Best Practice Changes
2.15 Sub-manifest Referencing Using the <dependency> Element
2.15.1 Reference to CP Issues List
2.15.2 Information Model Changes
2.15.3 XML Binding Changes
2.15.4 Best Practice Changes
2.16 Correction of the Item Element Multiplicity
2.16.1 Reference to CP Issues List
2.16.2 Information Model Changes
2.16.3 XML Binding Changes
2.16.4 Best Practice Changes
2.17 Declaring All Files in a Package's Manifest
2.17.1 Reference to CP Issues List
2.17.2 Information Model Changes
2.17.3 XML Binding Changes
2.17.4 Best Practice Changes
2.18 Removing References to Physical Files
2.18.1 Reference to CP Issues List
2.18.2 Information Model Changes
2.18.3 XML Binding Changes
2.18.4 Best Practice Changes
2.19 Miscellaneous Changes
2.19.1 Information Model
2.19.2 XML Binding
2.19.3 Best Practice Guide

3. Deliverables

Appendix A - The Initial Issues

About This Document
List of Contributors

Revision History

Index

1. Introduction

1.1 Content Packaging Overview

The IMS Content Packaging specification describes data structures, XML binding and accompanying best practices that are used to provide interoperability for Internet based content with content creation tools, learning management systems (LMS), and run time environments. The scope of the IMS Content Packaging specification is focused on defining interoperability between systems that wish to import, export, aggregate, and disaggregate Packages of content.

At the current time it is version 1.1.3 of the Content Packaging specification that is available in the Final Release form to the public. This was released in June 2003. In March 2004 a further maintenance review cycle for Content Packaging was started. This document describes the editorial amendments and errata corrections for the creation of the v1.1.4 maintenance release.

1.2 Scope and Context

This document describes amendments that should be made by adopters of the IMS Content Packaging specification v1.1.3, thereby creating the IMS Content Packaging v1.1.4 specification. Many typographical and elaborative changes were made to clarify and correct the supporting documents. The substantive differences between the v1.1.3 and the v1.1.4 specifications are limited to:

1.3 Structure of this Document

The structure of this document is:

2. Amendments and Errata Instructions
The resolution of the issues that were not deferred until a later release. Each instruction describes the changes to be made to the documentation;
3. Deliverables
The set of documents and supporting information that is released to form the IMS Content Packaging v1.1.4 specification;
Appendix A - The Initial Issues Presentation
The initial set of issues that were introduced as a part of this revision of the IMS Content Packaging specification.

1.4 Nomenclature

DTD
Document Type Definition
LMS
Learning Management System
PLIRI
Persistent Location Independent Resource Identifier
URI
Universal Resource Identifier
URL
Universal Resource Locator
W3C
World Wide Web Consortium
XML
Extensible Mark-up Language
XSD
XML Schema Data

1.5 References

[CP, 03a]
IMS Content Packaging Information Model v1.1.3, C.Smythe, A.Cooper, IMS Global Learning Consortium, Inc., October 2004.
[CP, 03b]
IMS Content Packaging XML Binding v1.1.3, C.Smythe, A.Cooper, IMS Global Learning Consortium, Inc., October 2004.
[CP, 03c]
IMS Content Packaging Best Practice Guide v1.1.3, C.Smythe, A.Cooper, IMS Global Learning Consortium, Inc., October 2004.

2. Amendments and Errata Instructions

2.1 Namespacing of 'xml:lang'

2.1.1 Reference to CP Issues List

Identifier Issue
CP113-24
Inconsistent name-spacing using xml:lang and x:lang.

2.1.2 Information Model Changes

No changes required.

2.1.3 XML Binding Changes

Amendment Instructions:
XSD file.
Ensure the schema declaration and import line is


<xsd:schema targetNamespace="http://www.imsglobal.org/xsd/imscp_v1p1" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" elementFormDefault="qualified" 
version="IMS CP 1.1.4">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" 
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
OR (for a local copy)
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" 
schemaLocation="xml.xsd"/>


The file xml.xsd must be a local copy of the W3C file: http://www.w3c.org/2001/03/xml.xsd. This W3C document is always updated.

2.1.4 Best Practice Changes

Amendment Instructions:
Best Practice Document.
Add the following paragraph to Section 5.1

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.

2.2 Conflicting Information on <organizations>

2.2.1 Reference to CP Issues List

Identifier Issue
CP113-41
Conflicting information describing the <organizations> element.

2.2.2 Information Model Changes

No changes required.

2.2.3 XML Binding Changes

Amendment Instructions:
XML Binding Document.
Change Section 3.1.2

From:

Description. Describes zero, one, or more structures or organizations for this package.

Multiplicity. Occurs zero, once, or more within a <manifest> element.

Attributes

  • default (required). Identifies the default organization to use. Data type = idref.

To:

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

Multiplicity. Occurs once within a <manifest> element.

Attributes

  • default (optional). Identifies the default organization to use. Data type = idref.

2.2.4 Best Practice Changes

No changes required.

2.3 Clarification on the Order of Elements in a Manifest

2.3.1 Reference to CP Issues List

Identifier Issue
CP113-47
Clarification on the Order of Elements in a Manifest.

2.3.2 Information Model Changes

Amendment Instructions:
Information Document.
Change Section 4.1

From:

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.

To:

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.

2.3.3 XML Binding Changes

No changes required.

2.3.4 Best Practice Changes

Amendment Instructions:
Best Practice Document.
Change Section 4.2

From:

A single <manifest> element is required at the top 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 <resources> element.

To:

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

2.4 Typographic Correction in Best Practice Guide

2.4.1 Reference to CP Issues List

Identifier Issue
CP113-50
Typographic correction in Best Practice Guide (Section 4.10).

2.4.2 Information Model Changes

No changes required.

2.4.3 XML Binding Changes

No changes required.

2.4.4 Best Practice Changes

Note: All the examples need to change "isVIsible" to "isvisible" and "True" and "False" to "true" and "false".

Amendment Instructions:
Best Practice Document.
Change the last example in Section 4.10

2.5 Remove Reference to the <variation> Element

2.5.1 Reference to CP Issues List

Identifier Issue
CP113-52
Remove remaining references to the <variation> element.

2.5.2 Information Model Changes

No changes required.

2.5.3 XML Binding Changes

Amendment Instructions:
XML Binding Document.
Change Section 3.4.1

From:

  • 'type' (required). A string that identifies the type of variant resource. This specification defines the type webcontent plus reserved terms that are used to denote the packaging of content defined by other IMS specifications, including Learning Design.

To:

  • 'type' (required). A string that identifies the type of resource. This specification defines the type webcontent plus reserved terms that are used to denote the packaging of content defined by other IMS specifications, including Learning Design.

Amendment Instructions:

XML Binding Document.

Remove from the Index under the entry for 'Elements':

variation 16

2.5.4 Best Practice Changes

Amendment Instructions:

Best Practice Document.

Remove from the Index under the entry for 'Elements':

variation 38

2.6 Correction for Online Validation of the Examples

2.6.1 Reference to CP Issues List

Identifier Issue
CP113-54
Online validation of examples doesn't work because the 'xsi:schemaLocation' recommendation in the Best Practice document has not been followed.

2.6.2 Information Model Changes

No changes required.

2.6.3 XML Binding Changes

Amendment Instructions:

XML Examples.

Change the examples so that they validate online using the code below: Note that each example must have its own unique identifier.

<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/10/XMLSchema-instance"  
   xsi:schemaLocation = "http://www.imsglobal.org/xsd/imscp_v1p1   
      http://www.imsglobal.org/xsd/imscp_v1p1p4.xsd 
      http://www.imsglobal.org/xsd/imsmd_v1p2 
      http://www.imsglobal.org/xsd/imsmd_v1p2p2.xsd "
   identifier="Manifest1-CEC3D3-3201-DF8E-8F42-3CEED12F4197"
   version="IMS CP 1.1.4">

2.6.4 Best Practice Changes

No changes required.

2.7 Clarification on the Length of the 'href' Attribute String

2.7.1 Reference to CP Issues List

Identifier Issue
CP113-69
Clarification on the length for the string contained in the 'href' attribute.

2.7.2 Information Model Changes

No changes required.

2.7.3 XML Binding Changes

No changes required.

2.7.4 Best Practice Changes

Amendment Instructions:

Best Practice Document.

Add as paragraph 2 in Section 4.8.3 "When the 'xml:base' attribute is used then 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."

2.8 Clarification on the Usage of External Meta-data

2.8.1 Reference to CP Issues List

Identifier Issue
CP113-48
Clarification on the usage of external meta-data in Best Practice Guide.

2.8.2 Information Model Changes

No changes required.

2.8.3 XML Binding Changes

No changes required.

2.8.4 Best Practice Changes

Amendment Instructions:
Best Practice Document.
Change Section 4.3.1

From:

"Some Content Packages will have their associated meta-data captured in a separate file. When this is the case, manifests may include an in-line reference to the external meta-data file."

To:

A Content Packaging implementation may, but doesn't 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.

2.9 Scoping of Meta-data in a Content Package

2.9.1 Reference to CP Issues List

Identifier Issue
CP113-89
Placing and scope of meta-data with a content package.

Note: There are dozens of places in all the documents where meta-data is referenced. These have been updated in accordance with the below statements.

2.9.2 Information Model Changes

No changes required.

2.9.3 XML Binding Changes

No changes required.

2.9.4 Best Practice Changes

Amendment Instructions:
Best Practice Document.
Change Section 4.3

From:

Meta-data is optional and is allowed within <manifest>, <resource>, <organization>, <item>, and <file> elements 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 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 IMS Meta-Data v1.2.1 Specification (the latest version), which contains approximately 86 meta-data elements that may be used to describe and catalog Content Packages, as the Package author sees fit.

To:

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

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

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

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

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

The complete set of meta-data elements available for describing and cataloging a content Package is not included with this specification. This specification recommends the best practice of using the IEEE LOM standard (see IMS Meta-Data v1.3 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.

2.10 Correction of the Parameter Construction Algorithm

2.10.1 Reference to CP Issues List

Identifier Issue
CP113-53
The normative parameter construction algorithm is not complete.

2.10.2 Information Model Changes

Amendment Instructions:
Information Model Document.
Change Section 4.2

From:

While first char of parameters is in"?&"
   Clear first char of parameters
If first char of parameters is "#"
  If the URI contains "#" or "?"
      Discard parameters;
      Done processing URI
If the URI contains "?"
  Append "&" to the URI
Append parameters to the URI

To:

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

2.10.3 XML Binding Changes

No changes required.

2.10.4 Best Practice Changes

No changes required.

2.11 Usage of Local and Remote XSDs for Instance Validation

2.11.1 Reference to CP Issues List

Identifier Issue
CP113-57
Clarification on the usage of local and remote XSDs for instance validation.

2.11.2 Information Model Changes

Amendment Instructions:
Information Model Document.
Change Section 2.2

From:

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

The IMS Manifest file and any of its supporting XML files (DTD, XSD) must be placed at the root of the Package Interchange File or any other packaging image (like a CD-ROM).

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.

To:

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.

2.11.3 XML Binding Changes

No changes required.

2.11.4 Best Practice Changes

No changes required.

2.12 The Usage of 'xml:base' in Sub-manifests

2.12.1 Reference to CP Issues List

Identifier Issue
CP113-58
How should 'xml:base' be used in sub-manifests?

2.12.2 Information Model Changes

No changes required.

2.12.3 XML Binding Changes

No changes required.

2.12.4 Best Practice Changes

Amendment Instructions:
Best Practice Document.
Change Section 4.8.3

From:

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

To:

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

2.13 Improved Guidance on Merging Sub-manifests

2.13.1 Reference to CP Issues List

Identifier Issue
CP113-59
More guidance or requirements are needed to explain sub-manifest merging process.

2.13.2 Information Model Changes

Amendment Instructions:
Information Model Document.
Change Section 4. 1

From:

If the (sub)Manifest includes an <organization> that can be used bythe context in which the content is used, the root node of thatorganization (i.e., the <organization> element itself) shall merge with the <item> that references the (sub)Manifest, if the <item> becomes instantiated. If the same attribute is specified for both the <item> and the <organization>, but with different values, the value defined for the <item> manifest shall override the value defined for the <organization>.

The diagram in Figure 4.2 explains how the content of a (sub)Manifestis virtually merged with the content of a referencing manifest. The circles represent <items> in an <organization> structure.

In Figure 4.2, the diagram explains how the content of a (sub)Manifestis merged with an <item> that has children of its own, and how the referencing <item>'s children take precedence over those they merge with.

To:

If the sub-manifest includes an organization, the root node of that organization (i.e., the organization element itself) shall merge with the item that references the sub-manifest. If the same attribute is specified for both the item and the organization it references, but with different values, the value defined for the referred organization manifest shall override the value defined for the referring item. That is, child attributes take precedence over parent attributes. This behavior is expected of the rendering of the navigation tree, but does not need to affect the XML of the manifest(s).

[insert a modified version of Figure 4.2]

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.

[insert a modified version of Figure 4.3]

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

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.

[insert a new diagram as Figure 4.4]

2.13.3 XML Binding Changes

No changes required.

2.13.4 Best Practice Changes

No changes required.

2.14 Clarification on the Default Attribute of the <organizations> Element

2.14.1 Reference to CP Issues List

Identifier Issue
CP113-60
Clarification on the use of the default attribute on the <organizations> element.

2.14.2 Information Model Changes

Amendment Instructions:
Information Model Document.
Change 'Notes' cell entry for row 1.5.1 ('Default') in Table 4.1

From:

If not supplied, the first organization element encountered is assumed to be the default.

To:

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.

2.14.3 XML Binding Changes

No changes required.

2.14.4 Best Practice Changes

No changes required.

2.15 Sub-manifest Referencing Using the <dependency> Element

2.15.1 Reference to CP Issues List

Identifier Issue
CP113-70
Sub-manifest referencing using the <dependency> element.

2.15.2 Information Model Changes

Amendment Instructions:
Information Model Document.
Change 'Notes' cell entry for row 1.6.2.7.1 ('Dependency') in Table 4.1

From:

<blank>

To:

This identifierref cannot reference an identifier in a sub-manifest.

2.15.3 XML Binding Changes

No changes required.

2.15.4 Best Practice Changes

No changes required.

2.16 Correction of the Item Element Multiplicity

2.16.1 Reference to CP Issues List

Identifier Issue
CP113-158
Item element multiplicity is not the same in the Info Model and Binding documents.

2.16.2 Information Model Changes

No changes required.

2.16.3 XML Binding Changes

Amendment Instructions:
XML Binding Document.
Change Figure 3.3

[insert a modified version of Figure 3.3]

Change Section 3.3.3 'Multiplicity' entry

From:

Multiplicity. Occurs zero or more times within <organization> and zero or more times within <item>.

To:

Multiplicity. Occurs one or more times within <organization> and zero or more times within <item>.

Amendment Instructions:

XML Binding Document. Change the XSD so that the <item> multiplicity in an <organization> is one or more times.

2.16.4 Best Practice Changes

No changes required.

2.17 Declaring All Files in a Package's Manifest

2.17.1 Reference to CP Issues List

Identifier Issue
CP113-161
'Extra files' in a Manifest.

2.17.2 Information Model Changes

No changes required

2.17.3 XML Binding Changes

No changes required.

2.17.4 Best Practice Changes

Amendment Instructions:
Best Practice Document
Change Section 4 "Conceptual Model Discussion"

From:

Resource - The resources described in the manifest are physical 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."

To:

Resource - The resources described in the manifest are physical 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.

All files included in the package should be declared and referenced in the manifest when interchanging packages. Including files in a package that are not mentioned in the manifest can lead to a wide range of problems when the package is imported into, run or re-exported from a receiving LMS or repository. This means, for example, that files such as web page 'spacer gifs' need to be declared as <file> elements within the web page's <resource> element in the package's manifest.

2.18 Removing References to Physical Files

2.18.1 Reference to CP Issues List

Identifier Issue
CP113-301
Fix the Info Model basic diagram.

2.18.2 Information Model Changes

Amendment Instructions:
Information Model Document
Figure 3.1

Replace words "PHYSICAL FILES" with "CONTENT"

[insert a modified version of Figure 3.1]

2.18.3 XML Binding Changes

No changes required.

2.18.4 Best Practice Changes

Amendment Instructions:
Best Practice Document
Figure 3.1


Replace "PHYSICAL RESOURCES" with "CONTENT"

[insert a modified version of Figure 3.1]

Figure 3.2

Replace words "PHYSICAL FILES" with "CONTENT"

[insert a modified version of Figure 3.2]

Figure 4.1

Replace words "PHYSICAL FILES" with "CONTENT"

[insert a modified version of Figure 4.1]

2.19 Miscellaneous Changes

2.19.1 Information Model

The following changes were also made to the Information Model document:

  1. Update the 'Front Page';
  2. Update the 'Table of Contents';
  3. Update the 'Introduction';
  4. Update the 'About This Document';
  5. Update the 'List of Contributors';
  6. Update the 'Revision History';
  7. Update the 'Index'.

2.19.2 XML Binding

The following changes were also made to the XML Binding document:

  1. Update the 'Front Page';
  2. Update the 'Table of Contents';
  3. Update the 'Introduction';
  4. Update the 'About This Document';
  5. Update the 'List of Contributors';
  6. Update the 'Revision History';
  7. Update the 'Index'.

2.19.3 Best Practice Guide

The following changes were also made to the Best Practice Guide document:

  1. Update the 'Front Page';
  2. Update the 'Table of Contents';
  3. Update the 'Introduction';
  4. Update the 'About This Document';
  5. Update the 'List of Contributors';
  6. Update the 'Revision History';
  7. Update the 'Index';
  8. Remove Appendix D;
  9. Add a new Appendix D that list the set of outstanding issues to be addressed in later versions.

3. Deliverables

The set of deliverables to be issued as the IMS Content Packaging v1.1.4 specification and documentation set is:

  1. IMS Content Packaging: Summary of Changes, Version 1.1.4 (this document);
  2. IMS Content Packaging Information Model, Version 1.1.4;
  3. IMS Content Packaging XML Binding, Version 1.1.4;
  4. IMS Content Packaging Best Practice and Implementation Guide, Version 1.1.4;
  5. IMS Content Packaging v1.1.4 XSD;
  6. IMS Content Packaging v1.1.4 Examples set.

Appendix A - The Initial Issues

In Table A1 is the list of original issues that were reviewed as part of the maintenance process. There are four possible states for the issue:

Table A1 List of issues reviewed as part of the maintenance process.

Issue Identifier Review Status Comment
CP113-24
Resolved
Inconsistent namespacing using 'xml:lang' and 'x:lang'.
Action: See sub-section 2.1 of this document.
CP113-25
Reject
Incorrect numbering of elements in the Information Model tabular description.
Action: Resolved as part of the CP v1.1.3 maintenance.
CP113-41
Resolved
Conflicting information describing the <organizations> element.
Action: See sub-section 2.2 of this document.
CP113-47
Resolved
Clarification on the Order of Elements in a Manifest.
Action: See sub-section 2.3 of this document.
CP113-48
Resolved
Clarification on the usage of external meta-data in Best Practice Guide.
Action: See sub-section 2.8 of this document.
CP113-49
Defer
Using URNs as identifiers or use PLIDs instead of xs:ID.
Action: Resolve as part of CP v1.2.
CP113-50
Resolved
Typographic correction in Best Practice Guide (Section 4.10).
Action: See sub-section 2.4 of this document.
CP113-51
Defer
Clarification on the usage of the 'isvisible' attribute.
Action: Resolve as part of CP v1.2.
CP113-52
Resolved
Remove remaining references to the <variation> element.
Action: See sub-section 2.5 of this document.
CP113-53
Resolved
Encoding parameters in URLs and the normative parameter construction algorithm is not complete.
Action: See sub-section 2.10 of this document.
CP113-54
Resolved
Online validation of examples doesn't work because the 'xsi:schemaLocation' recommendation in the Best Practice document has not been followed.
Action: See sub-section 2.6 of this document.
CP113-57
Resolved
Clarification on the usage of local and remote XSDs for instance validation.
Action: See sub-section 2.11 of this document.
CP113-58
Resolved
How should 'xml:base' be used in sub-manifests?
Action: See sub-section 2.12 of this document.
CP113-59
Resolved
More guidance or requirements are needed to explain sub-manifest merging process.
Action: See sub-section 2.13 of this document.
CP113-60
Resolved
Clarification on the use of the default attribute on the <organizations> element.
Action: See sub-section 2.14 of this document.
CP113-69
Resolved
Clarification on the length for the string contained in the 'href' attribute.
Action: See sub-section 2.7 of this document.
CP113-70
Resolved
Sub-manifest referencing using the <dependency> element.
Action: See sub-section 2.15 of this document.
CP113-71
Duplicate
Action: This is a duplicate of CP113-53 (see CP113-53 for the detailed resolution.
CP113-89
Resolved
Placing and scope of meta-data with a content package.
Action: See sub-section 2.9 of this document.
CP113-158
Resolved
Item element multiplicity is not the same in the Info Model and Binding documents.
Action: See sub-section 2.16 of this document.

About This Document

Title
IMS Content Packaging Summary of Changes
Editors
Colin Smythe (IMS), Alex Jackl (IMS), Wilbert Kraan (JISC)
Version
1.1.4
Version Date
04 October 2004
Status
Final Specification
Summary
This document presents the amendments and errata corrections that are to be made to the IMS Content Packaging v1.1.3 specifications to create the v1.1.4 release. The scope of these corrections is limited to editorial changes and errata corrections. This document should be used in conjunction with the IMS Content Packaging v1.1.4 specification documents.
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_sumcv1p1p4.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
Kerry Blinco
DEST
Pierre Gorissen
SURF
Andy Heath
IMS Europe
Alex Jackl
IMS
Wilbert Kraan
JISC (CETIS)
GianLuca Rolandelli
GIUNTI
Colin Smythe
IMS
Schawn Thropp
ADL
Raymond Yee
UC Berkeley

Revision History

Version No. Release Date Comments
Final 1.1.4
04 September 2004
The 'IMS Content Packaging Summary of Changes' document that describes the amendments and errata changes made to the IMS Content Packaging v1.1.3 specification.

Index

A
Aggregation 1, 2

B
Best Practice Guide 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
Binding 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24

C
Catalog 1
Content Package 1, 2, 3, 4, 5

E
Extension 1, 2

I
IEEE 1
IMS Specifications
Content Packaging 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25
Meta-Data 1
imsmanifest 1, 2
Information Model 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
Interoperability 1
isvisible 1, 2, 3

L
Learning 1
LMS 1, 2, 3
LOM 1

M
Manifest 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Meta-data 1, 2, 3, 4, 5, 6
Language 1
Version 1

N
Namespace 1, 2
Namespacing 1
Normative 1, 2, 3

P
Package Interchange File 1
Profile 1

R
Resource 1, 2, 3
Resources 1, 2
RFC 1
run time environment 1

S
Schema 1, 2, 3
SCORM 1
Structure 1
sub-Manifest 1

U
URI 1, 2, 3

V
Validation 1, 2, 3, 4, 5

W
W3C 1, 2, 3

X
XML 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
XSD 1, 2, 3, 4, 5, 6
XML Schema
DTD 1

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