1EdTech Content Packaging Summary of Changes

Version 1.1.4 Final Specification

<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="1EdTech 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 '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.

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.

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

From:

A single <manifest> element is required at the top of the 1EdTech Manifest file. There can be one and only one top-level <manifest> element. All other instances of a <manifest> element are nested within the <resources> element.

To:

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

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 1EdTech 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 1EdTech specifications, including Learning Design.

XML Binding Document.

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

variation 16

Best Practice Document.

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

variation 38

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="1EdTech CP 1.1.4">

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

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.

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 1EdTech 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 1EdTech CP Information model defines five places where meta-data can be used to describe different components of a content package:

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

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

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

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

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

From:

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

imsmanifest.xml

The 1EdTech 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 1EdTech 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 1EdTech Content Packaging specification must contain an 1EdTech Manifest file. To ensure that the 1EdTech Manifest file can always be found within a Package, it has a pre-defined name and location:

imsmanifest.xml

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

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

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.

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]

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.

From:

<blank>

To:

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

[insert a modified version of Figure 3.3]

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

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

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.

Replace words "PHYSICAL FILES" with "CONTENT"

[insert a modified version of Figure 3.1]

Replace "PHYSICAL RESOURCES" with "CONTENT"

[insert a modified version of Figure 3.1]

Replace words "PHYSICAL FILES" with "CONTENT"

[insert a modified version of Figure 3.2]

Replace words "PHYSICAL FILES" with "CONTENT"

[insert a modified version of Figure 4.1]