IMS Logo

IMS Content Packaging Information Model


Version 1.2 Public Draft v2.0

 

Date Issued:

01 March 2007

Latest Version:

http://www.imsglobal.org/content/packaging/index.html

Supersedes:

IMS Content Packaging Information Model v1.2 Internal Draft v2.0

Comments / Feedback:

http://www.imsglobal.org/community/forum/categories.cfm?catid=92

 

 

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

Intellectual property acknowledgements

“UML,” “Unified Modeling Language,” “OMG,” and “Object Management Group” are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

“Unicode” is a registered trademark of Unicode, Inc.

“W3C” is a trademark (registered in numerous countries) of the World Wide Web Consortium; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.

“XML,” “HTML,” “XHTML” are trademarks of the W3C; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.

“SCORM” is a registered trademark of the Advanced Distributed Learning Initiative, Office of the Deputy Under Secretary of Defense (Readiness), Readiness and Training, 1E525, 4000 Defense Pentagon, Washington, D.C. 20301.

 

Table of contents

Intellectual property acknowledgements 2

1. Introduction 5

1.1 Overview 5

1.2 Scope and context 6

1.3 Backwards compatibility 6

1.4 Structure of this document 6

2. Normative references 7

3. Definitions, acronyms, and abbreviations 8

3.1 Definitions 8

3.1.1 child-manifest 8

3.1.2 content 8

3.1.3 content file 8

3.1.4 control file 8

3.1.5 interchange package 8

3.1.6 launchable URI 8

3.1.7 local 9

3.1.8 logical package 9

3.1.9 manifest 9

3.1.10 manifest document 9

3.1.11 meta-data 9

3.1.12 namespace 9

3.1.13 organization 9

3.1.14 package 9

3.1.15 package interchange file (PIF) 9

3.1.16 package reader 9

3.1.17 package writer 10

3.1.18 referenced-manifest 10

3.1.19 relative reference 10

3.1.20 remote 10

3.1.21 resource 10

3.1.22 stand-alone resource 10

3.1.23 variants 10

3.2 Acronyms and abbreviations 10

4. Conformance 12

4.1 Normative wording 12

4.2 Interchange package instances 12

4.3 Package readers 12

4.4 Package writers 12

4.5 Extensions 12

5. The IMS Content Packaging conceptual model 13

6. Class definitions and relationship requirements 14

6.1 Key terms and concepts 14

6.2 Platform-independent model of the IMS Content Packaging Information Model 16

6.3 InterchangePackage class 16

6.4 Manifest class family 17

6.4.1 Manifest class 18

6.4.2 ManifestMetadata class 19

6.4.3 Schema class 20

6.4.4 SchemaVersion class 20

6.4.5 MetadataModel class 21

6.5 Organizations class family 22

6.5.1 Organizations class 23

6.5.2 Organization class 24

6.5.3 Title class 24

6.5.4 LingualTitle class 25

6.5.5 Item class 25

6.6 Resources class family 26

6.6.1 Resources class 27

6.6.2 Resource class 28

6.6.3 File class 29

6.6.4 Dependency class 29

6.7 Metadata Class 29

6.8 Variant class 31

6.9 IPointer class 32

6.10 Extension class 34

6.11 Characteristic classes 35

6.11.1 Base class 35

6.11.2 Default class 36

6.11.3 Href class 36

6.11.4 Identifier class 37

6.11.5 IdentifierRef class 37

6.11.6 IsVisible class 39

6.11.7 Language class 40

6.11.8 LinkHref class 40

6.11.9 LinkType class 41

6.11.10 Other class 41

6.11.11 Parameters class 42

6.11.12 Structure class 42

6.11.13 Type class 43

6.11.14 Version class 44

Annex A Bibliography 45

About this document 46

List of contributors 46

Revision history 47

Index 48

 

1. Introduction

1.1 Overview

The IMS Content Packaging Information Model describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content.

The IMS Content Packaging specification was initially conceived for the packaging of instructional content. The specification supports the description of content supporting a given learning activity, location of the content, and how these pieces of content may be organized for best instructional effect. As a result of wide adoption of the specification, millions of IMS content packages of instructional content are used in a variety of applications. IMS Content Packaging is a core specification referenced in the Advanced Distributed Learning (ADL) initiative’s Sharable Content Object Reference Model [SCORM, 04].

Adopters of IMS Content Packaging have extended its use beyond just the packaging of instructional content. IMS Content Packaging is now profiled by other IMS Specifications to package and exchange other types of data.

IMS Content Packaging Version 1.1 was completed in April 2001. Since then, there have been requests for mostly minor functional additions and corrections, resulting in the Version 1.1.x series of the IMS Content Packaging Specification, culminating with Version 1.1.4.

Requests for major functional additions were not included in the Version 1.1.x series and were accumulated as practice matured around implementing IMS Content Packaging. Evaluation of these requests in 2006, combined with feedback from the wider adopter community, indicated to IMS that this is the right time to make a significant update and definitive release for this specification.

The new functionality and clarifications incorporated in this Version 1.2 of IMS Content Packaging are:

a) The meanings of terms used within the specification have been clarified.

b) The use of (sub)manifests, now termed child-manifests, has been clarified and enhanced:

• Interpretation of an item pointing to a child-manifest has been clarified.

• New functionality allowing components of child-manifests to be precisely referenced and interpreted has been added.

• Support for external child-manifests has been added.

c) Support for external referenced meta-data files has been added.

d) All internal vocabularies have been removed and are now maintained through the IMS registration process and contained in the corresponding VDEX file (for the Type in Resource and Structure in Organization) [VDEX, 04c]1

e) A new resource type of “stand-alone” has been added that allows another package to be used as a piece of content.

f) The syntax and usage of the Base, Parameter, IsVisible, and Href Information Model classes has been clarified.

g) Support for variant resources has been added. This includes support for alternative resources for accessible content.

h) Support for Organization and Item titles in multiple languages has been added.

i) Support for interchange packages that contain only content and interchange packages that have no local content files has been clarified.

The documentation style for this Version 1.2 of IMS Content Packaging Specification has been substantially revised to reflect IMS Global Learning Consortium’s adoption of the Unified Modelling Language (UML).

1.2 Scope and context

The scope of the IMS Content Packaging Information Model is the description of data structures that can be used to exchange content among systems that wish to import, export, aggregate, and disaggregate packages of content.

The IMS Content Packaging Information Model Version 1.2 preserves the IMS Content Packaging Information Model Version 1.1.4 as its base model and introduces new functionality by extension of this base model.

This specification supersedes prior versions of the IMS Content Packaging information model documents and obsoletes all previous descriptions and definitions of the IMS Content Packaging Information Model.

The Extensible Markup Language (XML) Schema binding for IMS Content Packaging Information Model Version 1.2 and associated namespace identifiers are declared in the IMS Content Packaging XML Binding Version 1.2 [CP, 07b]. Practices related to the interpretation and implementation of the Information Model are covered in the IMS Content Packaging Best Practice and Implementation Guide Version 1.2 [CP, 07c].

1.3 Backwards compatibility

This document arises in an active implementation environment of ever increasing adoption of IMS Content Packaging. A primary goal of this document is to enable future growth while regularizing current practice. To that end, the following definition of backwards compatibility has guided the development of this IMS Content Packaging Information Model Version 1.2:

a) From the perspective of the IMS Content Packaging Information Model, the IMS Content Packaging Information Model v1.1.4 [CP, 04a] is a proper subset of IMS Content Packaging Information Model v1.2.

b) An XML instance of the IMS Content Packaging that validates against the IMS Content Packaging XML Binding v1.1.4 [CP, 04b] also validates against the IMS Content Packaging XML Binding v1.2 [CP, 07b].

c) The semantics of the IMS Content Packaging Information Model components persists between versions except where necessary to ensure disambiguation.

d) Deprecation of classes or behaviors will be announced at least one release before realization (as “flagged for deprecation”).

1.4 Structure of this document

The structure of the rest of this document is:

 

2. Normative References

Lists references to other standards and requests for comment cited in this document.

3. Definitions, Acronyms, and Abbreviations

Defines terms and expands acronyms and abbreviations used in this document.

4. Conformance

The set of conformance statements that shall be obeyed for conforming systems and document instances.

5. IMS Content Packaging conceptual model

Illustrates the conceptual structure of the IMS Content Packaging Information Model.

6. Class Definitions and Relationship Requirements

Covers the structural relationships, data-type, value-space, and number of occurrences permitted for each kind of information object.

2. Normative references

The following referenced documents are indispensable for the application of this specification. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

 

[IEEELOM]

“1484.12.1–2002 IEEE Standard for Learning Object Metadata,” The Institute of Electrical and Electronics Engineers, Inc., 2002. ISBN:0-7381-3297-7.

[ISO 639–1]

Codes for the representation of names of languages – Part 1: Alpha-2 code

[ISO 639–2]

Codes for the representation of names of languages – Part 2: Alpha-3 code

[ISO 3166–1]

Codes for the representation of names of countries and their subdivisions – Part 1: Country codes

[RFC2119]

“Keywords for use in RFCs to Indicate Requirement Levels,” S. Bradner, Internet Engineering Task Force, Network Working Group, Request for Comments: 1951, March 1997. http://www.ietf.org/rfc/rfc2119.txt

[RFC2234]

“Augmented BNF for Syntax Specifications: ABNF,” D. Crocker (Ed.), P. Overell, Internet Engineering Task Force, Network Working Group, Request for Comments: 2234, November 1997. http://www.ietf.org/rfc/rfc2234.txt

[RFC2396]

“Uniform Resource Identifiers (URI): Generic Syntax,” T. Berners-Lee, R. Fielding, L. Masinter, Internet Engineering Task Force, Network Working Group, Request for Comments: 2396, August 1998. http://www.ietf.org/rfc/rfc2396.txt

[RFC2732]

“Format for Literal IPv6 Addresses in URL’s,” R. Hinden, B. Carpenter, L. Masinter, Internet Engineering Task Force, Network Working Group, Request for Comments: 2732, December 1999. http://www.ietf.org/rfc/rfc2732.txt

[RFC3986]

“Uniform Resource Identifier (URI): Generic Syntax,” T. Berners-Lee, M. Suignard, Internet Engineering Task Force, Network Working Group, Request for Comments: 3986, January 2005. http://www.ietf.org/rfc/rfc3986.txt

[SDN07, 06]

IMS GLC Specification Development Note 7: UML Profile for Platform Independent Model Descriptions of Specifications for Data Models, C.Smythe, v1.0, IMS GLC, October 2006.

[SDN11, 06]

IMS GLC Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures, C.Smythe, v1.0, IMS GLC, July 2006.

[UCS]

“The Unicode Standard, Version 4.0.0, defined by: The Unicode Standard, Version 4.0,” The Unicode Consortium, Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1. http://www.unicode.org/versions/Unicode4.0.0/bookmarks.html

3. Definitions, acronyms, and abbreviations

3.1 Definitions

3.1.1 child-manifest

A complete, subordinate manifest contained by another manifest. A Manifest may contain one or more child-manifests. Alternatively, a manifest may include a reference to a child-manifest that is external to the interchange package. A child-manifest describes a complete logical package that is part of the larger logical package defined by its parent manifest. Child-manifests may be local or remote. See also: interchange package, local, logical package, manifest, remote.

3.1.2 content

A generic term for the logical units of usable (and re-usable) information described by a logical package. For example, in the instructional context content may be web-based instructional materials. A logical package may contain one or more units of content. See also: logical package.

3.1.3 content file

Individual computer files that embody the content described by the logical package. Content will often contain more than one content file. For example, web content is often instantiated by HTML, JPEG, and CSS files. Content files may be local or remote. See also: local, logical package, remote.

3.1.4 control file

Any file that governs the binding of the information model to make it suitable for machine processing. A software component may refer to a control file when assessing the validity of a bound instance of the information model or to guide the creation of a bound instance of the information model. For example, a file containing an XML schema may be used as a control file for an XML binding of a manifest.

3.1.5 interchange package

The set of components that are exchanged between systems. An interchange package shall include a manifest and may include content files and control files. All of the files included in an interchange package shall be described in the manifest or a child-manifest.

The interchange package is identical to the logical package when all components in the logical package are local to the interchange package. The criteria for determining the components of a logical package that should be included in the interchange package is out of scope for this specification and shall be determined by the implementer. Influencing factors may include the size of the instantiation of the interchange package, architectural reasons, and business policies.

An interchange package may be instantiated in a single compressed binary file (package interchange file) or as a collection of files on portable media (e.g., CD, DVD, USB memory device). See also: logical package, package interchange file.

3.1.6 launchable URI

A representation of a Universal Resource Locator (URL) that may be included in a resource description and that is used to locate and access the content described by the resource. The launchable Uniform Resource Identifier (URI) is not meant to be resolved by a package reader. The URI is meant to be stored for later use by other software components (e.g., a web browser) after the contents of a interchange package are processed. See also: interchange package, package reader.

3.1.7 local

Any component of the logical package that is contained within the interchange package is termed local to the interchange package. See also: logical package, interchange package.

3.1.8 logical package

A representation of one or more units of usable (and reusable) content. The logical package encompasses the full set of components described by the manifest and its child-manifests, including the local components and the remote components included by reference. See also: child-manifest, local, manifest, remote.

3.1.9 manifest

A description of a complete instance of a logical package. It describes resources in the logical package, their organization and the locations of the associated content and control files. A manifest may contain references to components that are local or remote. See also: local, logical package, remote.

3.1.10 manifest document

A Manifest object with contents that are structured according to an IMS Content Packaging XML binding.

3.1.11 meta-data

Descriptive information about logical packages, logical organizations, content, and files. Meta-data may be assigned to any of the core structures within the logical package including the manifest. Any binding of a meta-data object is permitted. Each object of meta-data may be local or remote. See also: local, logical package, remote.

3.1.12 namespace

A set of names in which each name is unique and has a semantic value distinct from any other member of the same set. The set need not have any internal structure.

3.1.13 organization

The logical relationships among units of content. More than one logical organization may be described in a manifest. An organization is bound to files through the relationship among item components and their referenced resource components of a manifest. See also: resource.

3.1.14 package

Always used in conjunction with a qualifier. The definitions of the qualified forms of package are given in this section. See also: content package, interchange package, logical package.

3.1.15 package interchange file (PIF)

A particular instantiation of an interchange package described in the information model. An interchange package may be instantiated in a format other than a package interchange file (PIF). For example, an interchange package may be instantiated as a collection of files on removable media, e.g., CD, DVD, USB memory device, or compressed using another format such as .tar, .jar, .cab. See also: interchange package.

3.1.16 package reader

A software component that reads a manifest and verifies the contents of an interchange package. A package reader may also process a logical package (e.g., retrieve and store information referenced by the manifest, unpack local files from a PIF, retrieve or log addresses of remote files, etc.) or delegate that task to another software component. See also: interchange package, logical package.

3.1.17 package writer

A software component that creates or modifies an instance of an interchange package and assembles content files and other files declared local to the interchange package and writes them to the targeted interchange package binding or delegates those tasks to another software component. See also: interchange package.

3.1.18 referenced-manifest

A manifest or a component of a manifest that is referenced from within another manifest. For example, a manifest may reference an organization in another manifest. The manifest containing the component being referenced is called a referenced-manifest. A manifest may contain references to components that are local or remote. See also: local, remote.

3.1.19 relative reference

A type of URI that refers to a resource by describing an extension to the reference context. The extension and the context are combined to create a target URI. For example, relative/path/to/resource.txt is a relative reference that is interpreted in terms of a context to be resolved. The algorithm for resolving relative references in terms of contexts is defined in section 5 of RFC3986.

3.1.20 remote

Any component of the logical package that is located outside the interchange package is termed remote to the interchange package. See also: interchange package, logical package.

3.1.21 resource

A description of a collection of files used by the logical package. The description may include meta-data about the collection of files, a description of each of the files, and information about variant forms of the collection of files. See also: logical package.

A resource is often used to describe a unit of content. When this is the case, the resource may contain a launchable URI for the content.

The files described by a resource may be local or remote. See also: launchable URI, local, remote.

3.1.22 stand-alone resource

A resource type that allows a manifest to declare a relationship to another manifest in such a way that the related manifests are processed as separate but related data sets. The related manifests may be contained within a single content package or accessible as an external URI addressable resource. Each manifest represents a stand-alone learning resource which may be aggregated with other learning resources to create arbitrarily rich learning experiences.

3.1.23 variants

A container for referencing and describing variant content. A particular resource may have variants of different formats and for different purposes. The listing of variants within a resource identifies alternative collections of files for the resource. Meta-data is used to describe the intended uses of the original resource and the intended uses of the variants. Examples include, but are not limited to, use as lingual variants, visual or auditory variants, remediation variants, and platform delivery variants. See also: meta-data, resource.

3.2 Acronyms and abbreviations

 

ABNF

Augmented Backus-Naur Form

ADL

Advanced Distributed Learning

PIF

Packaging Interchange File

PIM

Platform Independent Model

SCORM

Sharable Content Object Reference Model

UML

Unified Modeling Language

URI

Uniform Resource Identifier

XML

Extensible Markup Language

4. Conformance

This section focuses on the conformance expected of systems or applications that prepare or process instances of an interchange package. No requirement is made on application developers to use a specific programming language or set of heuristics when implementing the requirements described by this Information Model.

4.1 Normative wording

In this document, “shall” is to be interpreted as a requirement on an implementation; “shall not” is to be interpreted as a prohibition. “Should,” “should not,” and “may” shall be interpreted as described in RFC2119.

4.2 Interchange package instances

A conforming instance of an IMS Content Packaging Version 2.2 interchange package shall conform with the Information Model described in Section 6.

4.3 Package readers

A conforming reader of interchange packages shall read and interpret interchange packages as defined in Section 6.

4.4 Package writers

A conforming writer of interchange packages shall write interchange packages instances that conform with the Information Model described in Section 6.

4.5 Extensions

A conforming writer of interchange packages shall ascertain that a class from an extending namespace is congruent with the information type of the targeted extension point within the IMS Content Packaging Information Model. The semantics of an Extension object shall stay within the scope of the semantics of its parent object in this Information Model. The semantics of an Extension object shall not override or redefine the semantics of any parent object defined in this Information Model.

A conforming package reader shall not have any responsibility for ensuring that the semantics of any extending class preserves or extends a kind of container or value object in this document.

Conforming package readers shall not have an obligation to test the validity of any character strings expressed in extending children of File or File.Metadata that are presented file references

A conforming package reader shall not be obligated to interpret and process the content of extension classes. If a package reader does not process an extension object, it shall ignore the extension object without affecting processing of the remainder of the interchange package.

5. The IMS Content Packaging conceptual model

(Informative)

Figure 5.1 is a conceptual diagram that illustrates the structure of the IMS Content Packaging Information Model.

 

Figure 5.1 IMS Content Packaging conceptual model.

These core structural components are:

• Logical package – a representation of one or more units of usable (and reusable) content. The logical package encompasses the full set of components described by the manifest, including the local components and the remote components included by reference.

• Interchange package – the set of components that are to be exchanged between systems including the manifest and other selected files.

• Manifest – the component that describes a complete instance of a logical package. A manifest may contain references to components that are local or remote.

• Organizations – logical relationships among the units of content. More than one logical organization may be described.

• Resources – an inventory of content and files used by the parent manifest. The files may be local or remote.

• Child-manifests – complete and subordinate manifests that are contained within or referenced from a manifest. These each describe a complete logical package that is part of the larger logical package. The child-manifests may be local or remote.

• Files – computer files that embody the content described by the logical package or govern the binding of other files to make them suitable for machine processing. Content files may be local or remote.

• Meta-data – descriptive information about content packages, logical organizations, content, or files. In this diagram the meta-data box represents the set of local and/or remote meta-data objects that are contained within the logical package. Any binding of a meta-data object is permitted. Meta-data may be assigned to any of the core structures within the logical package including the manifest.

The information model defines these core structural components for describing and organizing content for exchange. An important underpinning is support for extensibility. Implementers of this specification may use these extension mechanisms to define new vocabulary terms and structures.

6. Class definitions and relationship requirements

An informative overview of the entire IMS Content Packaging Information Model is provided as a Platform Independent Model (PIM) expressed in UML constructs. All UML diagrams expressed as “Platform Independent Model” are non-normative. Normative tables defining the classes in this Information Model follow the informative UML diagrams.

A full definition of the UML Profile and the terms used in the normative tabular descriptions in this document to describe the PIM can be found in [SDN07, 06].

In the tables in this section the character sequence “n / a” is used to mark a field “not applicable.” Any field so marked is not relevant to the class being defined. Features so marked shall be ignored when binding a class defined by this Information Model.

Augmented Backus-Naur form (ABNF) is used to define certain rules in the tables. Augmented Backus-Naur form is defined in [RFC2234].

6.1 Key terms and concepts

Classes in this information model are classified into four abstract class types. These abstractions are bound to specific data structures for machine processing in the IMS Content Packaging XML Binding Version 1.2 [CP, 07b]. The four abstract class types are:

• container: A container class may be a parent of one or more child classes.

• value: A value class shall not be a parent. That is, it shall not be a composite of characteristic, container, value, or unspecified class types. A value class shall always be a child of a container class and shall have semantic value within the scope of its parent class’s semantic value.

• characteristic: A characteristic class shall not be a parent. A characteristic class shall declare a trait or value that is an intrinsic feature or part of a container class. A characteristic class is tightly coupled to the container class it modifies or one of which facets it describes.

• unspecified: An unspecified class may be a parent. An unspecified class serves as an extension point for this Information Model.

Table 6.1 lists the class descriptors used to describe the abstract classes and definitions of the descriptors.

Table 6.1 Class descriptors.

 

 

 

Descriptor

Definition

Class name

The name given to the class being described.

Class type

The abstract class type of this class.

Data type

For value and characteristic classes, the allowed structure for valid values for the class.

Valid data types are:

URI: Any syntactically valid instance of a URI as defined in RFC3986. Note: Many of the foundational Specifications, Standards, and Recommendations referred to by this Information Model use RFC2396 and RFC2732 as the definitions of URI. These are made obsolete by RFC3986, but many of the foundational documents have not been updated to reference RFC3986.

LUID: An identifier that is locally unique within a manifest. This will be based upon the String data-type that has a constrained value-space.

LUIDref: A reference to a LUID that has been defined elsewhere within a manifest. The value of the LUID and the LUIDref(s) that reference it shall be the same.

Boolean: The primitive, two-valued data type that uses the keywords “true” and “false” to indicate the logical state of an object.

String: A sequence of printable characters.

unspecified: The data type is not known or is not important.

Value space

The range of valid values for this class. If the value space is unspecified, it is not known or is not important.

Multiplicity

A property of a class indicating the number of times it may be used or appear in a given parent context. The values of this property are expressed as a range or shorthand for a range using this notation:

‘0..1’ [optional; restricted]

‘0..unbounded’ [optional; unrestricted]

‘1..1’ [mandatory; restricted]

‘1..unbounded’ [mandatory; unrestricted]

Multiplicities may also appear in short-hand notation in the UML models. The short-hand equivalents shall be (exclusive of bracketed comments):

‘*’ [optional; unrestricted]

‘1’ [mandatory; restricted]

‘1..*’ [mandatory; unrestricted]

Where multiplicity is greater than one, the importance of the ordering of siblings is also indicated by appending either “,”ordered or “,” unordered.

ordered specifies a sequence of siblings as listed, unordered specifies a collection or bag of siblings. Order is not important.

Characteristic classes

Lists the characteristic classes associated with this class in the form “{“ characteristic *“,” characteristic “}”. One or more characteristics may be expressed within curly braces. Each characteristic shall be separated by a comma.

Where more than one characteristic is listed, the importance of the ordering of siblings is also indicated by appending either “,”ordered or “,” unordered.

ordered specifies sequence of siblings as listed, unordered specifies a collection or bag of siblings. Order is not important.

Parents

Lists classes that may be parents of this class.

Children

Lists the possible child classes of this class in the form “[” child *“,” child “]”. One or more child classes may be expressed within square brackets. Each child class shall be separated by a comma.

Where more than one child is listed, the importance of the ordering of siblings is also indicated by appending either “,”ordered or “,” unordered.

ordered specifies a sequence of siblings as listed, unordered specifies a collection or bag of siblings. Order is not important.

Description

Contains descriptions relating to the class and its values space.

6.2 Platform-independent model of the IMS Content Packaging Information Model

Figure 6.1 is a visual summary of the structure of the IMS Content Packaging Information Model.

 

Figure 6.1 Structural view of the Content Packaging PIM (overview).

The structural view in Figure 6.1 is focused on the relationships among the primary classes. It does not contain the details of the multiplicities, ordering, or attributes for the classes.

6.3 InterchangePackage class

Table 6.2 defines the InterchangePackage class in the IMS Content Packaging Information Model.

Table 6.2 InterchangePackage class definition.

 

 

 

Descriptor

Definition

Class name

InterchangePackage

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

1..1

Characteristic classes

n / a

Parents

none

Children

[Manifest]

Description

An InterchangePackage object is the subset of a logical package that is exchanged between systems. An InterchangePackage shall meet the following conditions:

a) The InterchangePackage shall include a Manifest object and may include content files and control files.

b) Any file described in the Manifest using a URI that resolves to a location within the InterchangePackage shall be included in the InterchangePackage.

c) All files included in an InterchangePackage shall be described in the Manifest.

d) Files contained in the InterchangePackage may contain internal references to other files (e.g., a HTML content file may reference a JPEG content file, or an XML Schema control file may reference another XML Schema control file). When a file contained in an InterchangePackage references another file using a URI that resolves to a location within the InterchangePackage, the referenced file shall be described in the InterchangePackage’s Manifest.

A package interchange file (PIF) is a particular instantiation of an InterchangePackage. Package readers and writers are not obliged to support the reading or writing of PIFs. A PIF shall meet the following conditions:

a) Physical encapsulation shall be as a compressed binary file conforming to RFC1951.

b) A PIF shall contain a single IMS manifest document object at the root of the PIF. That object shall be bound as an XML document named imsmanifest.xml. This document is called the root IMS manifest document for the PIF.

c) Any control files included in the PIF shall be placed at the root of the PIF.

d) All references from within the root IMS manifest document to files contained in the PIF shall be via relative reference. The references shall be relative to the root of the PIF.

e) A PIF shall not include any file with an absolute path (declared or resolved from a relative reference) higher than that of the IMS manifest document object in the same hierarchical path, or when their absolute path is completely distinct from the location of an IMS manifest document.

6.4 Manifest class family

This section defines the following classes in the IMS Content Packaging Information Model:

• Manifest

• ManifestMetadata

• Schema

• SchemaVersion

• MetadataModel

This section also defines relationships with the following classes defined in Sections 6.5.1, 6.6.1, 6.9, and 6.10, respectively:

• Organizations

• Resources

• IPointer

• Extension

Figure 6.2 shows the Manifest class PIM.

 

Figure 6.2 Simplified view of the Manifest class PIM.

6.4.1 Manifest class

Table 6.3 defines the Manifest class in the IMS Content Packaging Information Model.

Table 6.3 Manifest class definition.

 

 

 

Descriptor

Definition

Class name

Manifest

Class type

Container

Data type

n / a

Value space

n / a

Multiplicity

1..1 as child of InterchangePackage

0..unbounded as child of Manifest, unordered

Characteristic classes

{ Identifier, Version, Base, Other }, unordered

Parents

InterchangePackage

Manifest

Children

[ ManifestMetadata, Organizations, Resources, Manifest, IPointer, Extension ], ordered

Description

A Manifest object is a container for the data structures that describe a complete instance of a logical package.

A Manifest may contain child objects of the Manifest class (child-manifests). Child-manifests define complete instances of logical packages that are part of the larger logical package. A Manifest may also contain child objects of the IPointer class that reference child-manifests external to the Manifest. Any combination of child-manifests and externally referenced child-manifests are permitted and their order within the Manifest is not significant. Appropriate targets for an IPointer declared as a direct child of a Manifest are defined in Section 6.9.

A Manifest may contain references to components that are local or remote to its ancestor InterchangePackage object. References are made via Resource, File, and IPointer child objects. Resource and File are used to reference content files and control files. IPointer is used to identify referenced-manifests.

A Manifest shall contain File objects that describe all of the control files needed to interpret the Manifest.

6.4.2 ManifestMetadata class

Table 6.4 defines the ManifestMetadata class in the IMS Content Packaging Information Model.

Table 6.4 ManifestMetadata class definition.

 

 

 

Descriptor

Definition

Class name

ManifestMetadata

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..1

Characteristic classes

n / a

Parents

Manifest

Children

[ Schema, SchemaVersion, IPointer, MetadataModel ], ordered

Description

A ManifestMetadata object contains descriptive information about its parent Manifest object. The scope of ManifestMetadata is the entire logical package described by the parent Manifest.

The Schema and SchemaVersion children of ManifestMetadata provide information about the specification or profile that governs the meaning of the parent Manifest.

A MetadataModel child of ManifestMetadata serves as a placeholder for general descriptive information about its parent Manifest. MetadataModel is an extension point that allows meta-data with an information structure that is defined in another namespace. Multiple, differing meta-data models may be declared as extensions contained within a single ManifestMetadata object.

If the meta-data is defined in an external Metadata object, then the link to that object is achieved using an IPointer object. Any combination of MetadataModel and externally referenced meta-data is permitted and their order within the Metadata object is not significant Appropriate targets for IPointer declared as a child of ManifestMetadata are defined in Section 6.9.

6.4.3 Schema class

Table 6.5 defines the Schema class in the IMS Content Packaging Information Model.

Table 6.5 Schema class definition.

 

 

 

Descriptor

Definition

Class name

Schema

Class type

value

Data type

string

Value space

repertoire of printable characters from [UCS]

Multiplicity

0..1

Characteristic classes

n / a

Parents

ManifestMetadata

Children

n / a

Description

A Schema object declares the name of a specification or profile for its parent Manifest object. The value of Schema informs a package reader of the specification or profile that governs the meaning of the Manifest. This value should not be confused with the name or label assigned to a given meta-data schema.

No requirements are placed on the contents or syntax of a string declared as the value of a Schema, except that the string shall not include any versioning information. The default value shall be “IMS Content”.

6.4.4 SchemaVersion class

Table 6.6 defines the SchemaVersion class in the IMS Content Packaging Information Model.

Table 6.6 SchemaVersion class definition.

 

 

 

Descriptor

Definition

Class name

SchemaVersion

Class type

value

Data type

string

Value space

repertoire of printable characters from [UCS]

Multiplicity

0..1

Is extension point

false

Characteristic classes

n / a

Parents

ManifestMetadata

Children

n / a

Description

A SchemaVersion object declares the version of the specification or profile that is declared as a value for its sibling Schema object. This value informs a package reader of the version of the model or profile identified by a sibling Schema. A value for SchemaVersion shall include no other information. The default value shall be “1.2” when “IMS Content” is declared as the value for its sibling Schema and the manifest document is governed by a binding of this Information Model.

Neither a syntax for version information nor a heuristic for applying any versioning syntax is specified by this Information Model.

6.4.5 MetadataModel class

Table 6.7 defines the MetadataModel class in the IMS Content Packaging Information Model.

Table 6.7 MetadataModel class definition.

 

 

 

Descriptor

Definition

Class name

MetadataModel

Class type

unspecified

Data type

unspecified

Value space

unspecified

Multiplicity

0..unbounded, ordering also unspecified

Characteristic classes

unspecified, ordering also unspecified

Parents

ManifestMetadata

Metadata

Children

unspecified, ordering also unspecified

Description

A MetadataModel object is a placeholder. It informs bindings of this Information Model as to the valid locations for the inclusion of meta-data in an interchange package.

The actual names of extending container or value class types comprising one or more meta-data models will be known only when a binding of those classes is imported into a bound instance of this Information Model. Hence, the actual type of class is unspecified in this Information Model.

MetadataModel is used by two meta-data containers: ManifestMetadata and Metadata. MetadataModel is the only means for expressing meta-data models and associated information in a bound instance of this Information Model.

A package writer may express as many different meta-data models as is needed to adequately describe the contents encapsulated by MetadataModel’s parent object.

MetadataModel shall be used only for declaring one or more meta-data models and information associated with them. The semantics of MetadataModel shall stay within the semantics of its parent in this Information Model. The semantics of MetadataModel shall not override or redefine the semantics of its parent as defined in this Information Model.

6.5 Organizations class family

This section defines the following classes in the IMS Content Packaging Information Model:

• Organizations

• Organization

• Title

• LingualTitle

• Item

It also defines relationships with the following classes defined in Sections 6.7, 6.9, and 6.10, respectively:

• Metadata

• IPointer

• Extension

Figure 6.3 shows the Organizations class PIM.

 

Figure 6.3 Simplified view of the Organizations class PIM.

6.5.1 Organizations class

Table 6.8 defines the Organizations class in the IMS Content Packaging Information Model.

Table 6.8 Organizations class definition.

 

 

 

Descriptor

Definition

Class name

Organizations

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

1..1

Characteristic classes

{ Default, Other }, unordered

Parents

Manifest

Children

[ Organization, IPointer, Extension ], ordered

Description

An Organizations object is a container for classes describing logical relationships among Resources objects. More than one logical organization may be described using either Organization or IPointer children of Organizations. The order of Organization and IPointer objects is not significant.

Organizations defined in referenced-manifests are identified using IPointer. Appropriate targets for IPointer declared as a child of Organizations are defined in Section 6.9.

6.5.2 Organization class

Table 6.9 defines the Organizations class in the IMS Content Packaging Information Model.

Table 6.9 Organization class definition.

 

 

 

Descriptor

Definition

Class name

Organization

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..unbounded, ordered

Characteristic classes

{ Identifier, Structure, Other }, unordered

Parents

Organizations

Children

[ Title, LingualTitle, Item, IPointer, Metadata, Extension ], ordered

Description

An Organization object is a container for classes describing a particular logical relationship between the Resource objects encapsulated by a Manifest object. Multiple Organization objects are equivalent in purpose. Each shows a way for structuring the same set of Resource objects within a given Manifest, though each Organization should show a different structure.

Item child objects are used to represent structural nodes within an Organization. Item objects defined in referenced-manifests are identified using IPointer objects. Any combination of Item and IPointer objects is permitted and the order of the objects is significant. Appropriate targets for IPointer declared as a child of an Organization are defined in Section 6.9.

At least one child Item or IPointer shall be declared for each Organization.

6.5.3 Title class

Table 6.10 defines the Title class in the IMS Content Packaging Information Model.

Table 6.10 Title class definition.

 

 

 

Descriptor

Definition

Class name

Title

Class type

value

Data type

string

Value space

repertoire of printable characters from [UCS]

Multiplicity

0..1

Characteristic classes

n / a

Parents

Organization

Item

Children

n / a

Description

A Title object contains a textual value applied to an Organization or Item object to name or label the structures each represents.

The textual value has no language type. The value of a Title is a string of characters. Implementers that desire one or more language-sensitive representations of a string of characters for a title should use the LingualTitle class.

6.5.4 LingualTitle class

Table 6.11 defines the LingualTitle class in the IMS Content Packaging Information Model.

Table 6.11 LingualTitle class definition.

 

 

 

Descriptor

Definition

Class name

LingualTitle

Class type

value

Data type

string

Value space

repertoire of printable characters from [UCS]

Multiplicity

0..unbounded, unordered

Characteristic classes

{ Language }

Parents

Organization

Item

Children

n / a

Description

A LingualTitle object contains a language-specific textual value applied to an Organization or Item object to name or label the structures each represents. The language of LingualTitle is specified by a Language object.

6.5.5 Item class

Table 6.12 defines the Item class in the IMS Content Packaging Information Model.

Table 6.12 Item class definition.

 

 

 

Descriptor

Definition

Class name

Item

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

1..unbounded, ordered

Characteristic classes

{ Identifier, IdentifierRef, IsVisible, Parameters, Other }, unordered

Parents

Organization

Item

Children

[ Title, Item, IPointer Metadata, Extension ], ordered

Description

An Item object is a container for representing a structural node in a particular Organization or in another Item object.

Item objects may contain child Item or IPointer objects, each representing a unique structural node. Items defined in referenced-manifests are identified using the IPointer class. Any combination of Item and IPointer is permitted within an Item, and the order of the objects is significant. Appropriate targets for IPointer declared as a child of an Item are defined in Section 6.9.

An Item may use an IdentifierRef object to express an internal reference to a Resource object that is to be associated with its structural role and position.

An Item may use IdentifierRef to express an internal reference to a child-manifest object that is to be associated with its structural role and position. The result of the reference is as if:

a) the referencing Item and all of its descendants are replaced with the collection of objects contained in the default Organization of the referenced child-manifest or the first Organization in the referenced child-manifest, if the referenced child-manifest does not have a default Organization;

b) the sibling Item objects of the replaced referencing Item are displaced in the sequence of child objects by the indirectly referenced Item and its siblings.

A package reader need not actually create a memory model or a data-storage model that mimics an actual splicing or joining of the two structures described above. However, the package reader shall interpret the reference as if the structure described above had been created.

6.6 Resources class family

This section defines the following classes in the IMS Content Packaging Information Model:

• Resources

• Resource

• File

• Dependency

It also defines relationships with the following classes defined in Sections 6.7, 6.8, 6.9, and 6.10, respectively:

• Metadata

• Variant

• IPointer

• Extension

Figure 6.4 shows the Resources class PIM.

 

Figure 6.4 Simplified view of the Resources class PIM.

6.6.1 Resources class

Table 6.13 defines the Resources class in the IMS Content Packaging Information Model.

Table 6.13 Resources class definition.

 

 

 

Descriptor

Definition

Class name

Resources

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

1..1

Characteristic classes

{ Base, Other }, unordered

Parents

Manifest

Children

[ Resource, IPointer, Extension ], ordered

Child grouping model

ordered

Description

A Resources object is a container for all information about files used by the parent Manifest object. The files may be local or remote.

Resources describes files for its parent Manifest. Reference files in any other Manifest object, including Manifest objects that are siblings to, descendants of, or ancestors of the parent Manifest, are out of the Resources object’s scope.

The Resource and IPointer children of the Resources object are used to describe a particular collection of files. IPointer is used to identify a Resource in a referenced-manifest. The order of the child Resource and IPointer objects is not significant. Appropriate targets for an IPointer child of a Resources object are defined in Section 6.9.

6.6.2 Resource class

Table 6.14 defines the Resource class in the IMS Content Packaging Information Model.

Table 6.14 Resource class definition.

 

 

 

Descriptor

Definition

Class name

Resource

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..unbounded, unordered

Characteristic classes

{ Identifier, Type, Base, Href, Other }, unordered

Parents

Resources

Children

[ Metadata, File, Dependency, Variant, Extension ], ordered

Description

A Resource object is a container for information relating to a particular collection of files used by the ancestor Manifest object.

Variant resources are identified using the Variant class. The relationship between the parent Resource and the set of Variant objects shall be described using meta-data in the variant resources.

A value declared by a Resource{ Href } object is a launchable URI.

A file reference declared in a Resource{ Href } shall have an associated declaration in a File object in the same Resource. The Href of the associated File object shall reference the same file as the Resource{ Href }. The Resource{ Href } and associated File{ Href } URIs may differ in that the Resource{ Href } may contain “launch” parameters in the URI.

6.6.3 File class

Table 6.15 defines the File class in the IMS Content Packaging Information Model.

Table 6.15 File class definition.

 

 

 

Descriptor

Definition

Class name

File

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..unbounded, unordered

Characteristic classes

{ Href, Other }, unordered

Parents

Resource

Children

[ Metadata, Extension ], ordered

Description

A File object is a container for all information relating to a single computer file, encapsulated by its parent Resource object. A File holds meta-data describing a computer file and a reference to the location of the file.

6.6.4 Dependency class

Table 6.16 defines the Dependency class in the IMS Content Packaging Information Model.

Table 6.16 Dependency class definition.

 

 

 

Descriptor

Definition

Class name

Dependency

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..unbounded, unordered

Is extension point

false

Characteristic classes

{ IdentifierRef, Other }, unordered

Parents

Resource

Children

[ Extension ]

Description

A Dependency object allows a Resource object to reference the collection of files described in a sibling Resource object.

Dependency shall use an IdentifierRef object to reference a Resource or an IPointer object. The referenced Resource or IPointer shall be encapsulated by the Dependency’s grandparent Resources object. If the reference is to an IPointer, then the IPointer shall reference a Resource within the referenced–manifest.

The result of the reference is that the files included in the scope of a referenced Resource shall be considered within the scope of the referencing Dependency’s parent Resource. The characteristic objects associated with the referenced Resource shall not be considered in scope of the referencing Dependency’s parent Resource.

6.7 Metadata Class

This section defines the Metadata class abstraction that is part of the IMS Content Packaging Information Model. It also defines relationships with the following object defined in Section 6.9:

• IPointer

Figure 6.5 shows the Metadata class PIM.

 

Figure 6.5 Simplified view of the Metadata class PIM.

Table 6.17 defines the Metadata class in the IMS Content Packaging Information Model.

Table 6.17 Metadata class definition.

 

 

 

Descriptor

Definition

Class name

Metadata

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..1

Characteristic classes

none

Parents

Organization

Item

Resource

File

Children

[ IPointer, MetadataModel ], xor

Description

A Metadata object contains descriptive information about its parent containers-class-type object. The scope of Metadata is the parent container class only.

The MetadataModel child object serves as a container for general descriptive information about its parent. MetadataModel is an extension point that allows meta-data with an information structure that is defined in another namespace. Multiple, differing meta-data models may be declared as extensions contained within a single MetadataModel object.

If the meta-data is defined in an external object, then the link to that object is achieved using an IPointer object. Any combination of MetadataModel and externally referenced meta-data is permitted, and their order within the Metadata object is not significant. Appropriate targets for IPointer declared as a child of Metadata are defined in Section 6.9.

6.8 Variant class

This section defines the Variant class that is part of the IMS Content Packaging Information Model. It also defines relationships with the following classes defined Sections 6.6.2 and 6.7, respectively:

• Resource

• Metadata

Figure 6.6 shows the Variant class PIM.

 

Figure 6.6 Simplified view of the Variant class PIM.

Table 6.18 defines the Variant class in the IMS Content Packaging Information Model.

Table 6.18 Variant class definition.

 

 

 

Descriptor

Definition

Class name

Variant

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

1..unbounded, unordered

Characteristic classes

{ Identifier, IdentifierRef, Other }, unordered

Parents

Resource

Children

[ Metadata, Extension ], ordered

Description

A Variant object allows a Resource object to reference and describe a variant Resource object.

A Variant shall use an IdentifierRef object to reference a Resource or an IPointer object. The referenced Resource or IPointer shall be encapsulated by the Variant’s grandparent Resources object. If the reference is to an IPointer, then the IPointer shall reference a Resource within the referenced–manifest.

The Metadata child object for the Variant should be used to describe the relationship between the Variant and the parent Resource.

6.9 IPointer class

This section defines the IPointer class that is part of the IMS Content Packaging Information Model. It also defines relationships with the following classes defined in Sections 6.4.1, 6.4.2, 6.7, 6.5.1, 6.5.2, 6.5.5, and 6.6.1, respectively:

• Manifest

• ManifestMetadata

• Metadata

• Organizations

• Organization

• Item

• Resources

Figure 6.7 shows the IPointer class PIM.

 

Figure 6.7 Simplified view of the IPointer class PIM.

Table 6.19 defines the IPointer class in the IMS Content Packaging Information Model.

Table 6.19 IPointer class definition.

 

 

 

Descriptor

Definition

Class name

IPointer

Class type

container

Data type

n / a

Value space

n / a

Multiplicity

0..unbounded, ordered

Characteristic classes

{ Identifier, LinkType, LinkHref, Other }, unordered

Parents

Manifest

ManifestMetadata

Metadata

Organizations

Organization

Item

Resources

Children

n / a

Description

An IPointer object is a linking object. Its purpose is to identify a node set in a manifest document and associate that node set with its parent. The source of the identified node set may be either be local or remote.

The node set that is identified by the IPointer shall be a valid child of the IPointer’s parent class (see Table 20).

Table 6.20 defines the permitted combinations of parent-class-to-target-class linking allowed using the IPointer class.

Table 6.20 Permitted linking combinations of parent/target classes.

 

 

 

Parent class of the IPointer class

Valid target nodeset for the IPointer class

Manifest

Manifest

Organizations

Organization

Organization

Item

Item

Item

Resources

Resource

ManifestMetadata

MetadataModel

Metadata

MetadataModel

6.10 Extension class

This section defines the Extension class placeholder that is part of the IMS Content Packaging Information Model. Figure 6.8 shows the Extension class PIM.

 

Figure 6.8 Simplified view of the Extension class PIM.

Table 6.21 defines the Extension class in the IMS Content Packaging Information Model.

Table 6.21 Extension class definition.

 

 

 

Descriptor

Definition

Class name

Extension

Class type

unspecified

Data type

unspecified

Value space

unspecified

Multiplicity

0..unbounded, ordered

Is extension point

true

Characteristic classes

unspecified, ordering also unspecified

Parents

Manifest

Organizations

Organization

Item

Resources

Resource

Variant

File

Dependency

Children

unspecified, ordering also unspecified

Description

An Extension object is a placeholder. It informs bindings of this Information Model as to the valid locations for the inclusion of value or container classes that extend any class of type container in this Information Model.

The Extension class is one of two mechanisms for extending any class of type container in this Information Model. The second extension mechanism is the Other class.

An Extension object is used to extend classes of type container.

The actual name of an extending container or value class type used in place of an Extension object will be known only when a binding of that object is imported into a bound instance of this Information Model. Hence, the actual type of class is unspecified in this Information Model.

The semantics of Extension shall stay within the scope of the semantics of its parent object in this Information Model. The semantics of Extension shall not override or redefine the semantics of any parent object defined in this Information Model.

6.11 Characteristic classes

6.11.1 Base class

Table 6.22 defines the Base class in the IMS Content Packaging Information Model.

Table 6.22 Base class definition.

 

 

 

Descriptor

Definition

Class name

Base

Class type

characteristic

Data type

URI

Value space

Binding language dependent.

Multiplicity

0..1

Parents

Manifest

Resources

Resource

Description

A Base object is used to specify an object's base URI for the object with which Base is associated for the purpose of resolving relative references that appear in descendants of the associated object.

The scope of Base’s value shall apply to all descendants of the object with which Base is associated, unless the value declared for Base is replaced or amended by a subsequent Base object in a permitted descendant.

All relative path segments expressed as a value for Base shall resolve to the manifest document containing those expressions. Relative path segments shall be constructed in such a way that the segment expressed Base can be appended to a relative path segment expressed in the nearest ancestor object expressing a value in its Base object and so on up to the root Manifest object. The resulting sequence of collected relative path segments shall then be appended to the location at which the manifest document is located or being processed to create an absolute path. Relative references appearing within the scope of a Base object shall then be interpreted according to the rules defined in RFC3986.

6.11.2 Default class

Table 6.23 defines the Default class in the IMS Content Packaging Information Model.

Table 6.23 Default class definition.

 

 

 

Descriptor

Definition

Class name

Default

Class type

characteristic

Data type

Binding language dependent (the default is string).

Value space

the value of an Organizations{ Default }.Organization{ Identifier } object

Multiplicity

0..1

Parents

Organizations

Description

A Default object designates a single child Organization object of an Organizations object as the primary or default organizing structure for a given Manifest object.

The designation of a default Organization shall be done by referencing the value of the Identifier object of the target Organization object. A target Organization shall be a child of an Organizations object that has a Default. No other reference by Default shall be permitted.

When a Default is not declared for an Organizations object, the first defined Organization object in an Organizations object shall be considered the primary or default organizing structure.

6.11.3 Href class

Table 6.24 defines the Href class in the IMS Content Packaging Information Model.

Table 6.24 Href class definition.

 

 

 

Descriptor

Definition

Class name

Href

Class type

characteristic

Data type

URI

Value space

as defined by RFC3986.

Multiplicity, by parent object

0..1 : Resource

1..1 : File

Parents

Resource

File

Description

An Href object is used to locate a resource.

A value declared for Href shall be a syntactically valid URI. This document makes no guarantee that a string so declared is a valid URI or will resolve to an actual resource or part of a resource at the location so identified.

A value declared for Manifest.Resources.Resource{Href} represents a URL that can be used to locate and access the content described by the resource. A package reader is not required to resolve the URI. The URI is meant to be stored for later use by other software components after the contents of an interchange package are processed.

A value declared for Manifest.Resources.Resource.File{Href}shall be a locator for a single digital resource, with no other implication as to the use of the resource so identified.

6.11.4 Identifier class

Table 6.25 defines the Identifier class in the IMS Content Packaging Information Model.

Table 6.25 Identifier class definition.

 

 

 

Descriptor

Definition

Class name

Identifier

Class type

characteristic

Data type

Binding language dependent Locally Unique Identifier (LUID).

Value space

Binding language dependent.

Multiplicity

1..1

Parents

Manifest

Organization

Item

Resource

IPointer

Variant

Description

An Identifier object uniquely identifies that Identifier object’s parent within a Manifest object. That is, only one occurrence of a given value for an Identifier may occur within the same Manifest, including that Manifest’s child-manifest objects.

A value for Identifier may be used for internal referencing from another object using an IdentifierRef object.

6.11.5 IdentifierRef class

Table 6.26 defines the IdentifierRef class in the IMS Content Packaging Information Model.

Table 6.26 IdentifierRef class definition.

 

 

 

Descriptor

Definition

Class name

IdentifierRef

Class type

Characteristic

Data type

Binding language dependent reference to an existing LUID (LUIDref).

Value space

A value for an Identifier object in the IdentifierRef object’s immediately containing Manifest object, and as further constrained by internal referencing rules defined below.

Multiplicity, by parent objects

0..1 : Item

1..1 : Dependency

1..1 : Variant

Parents

Item

Dependency

Variant

Description

An IdentifierRef object shall duplicate exactly a value for an Identifier object that is a descendant of the IdentifierRef object’s immediately containing Manifest object. An object’s immediately containing Manifest is defined as the first encountered Manifest in the object’s chain of ancestors. The referenced Identifier may be in a child-manifest of the immediately containing Manifest.

In addition, IdentifierRef is limited by the following internal referencing rules:

A. An IdentifierRef child of an Item object may reference one of:

i) A Resource or IPointer object that is a descendant of the referencing Item’s immediately containing Manifest object.

ii) A Manifest or IPointer that is a descendant of the referencing Item’s immediately containing Manifest

iii) A Resource or IPointer that is contained within a child-manifest object that is a descendant of the referencing Item’s immediately containing Manifest.

No reference shall be allowed from an IdentifierRef of an Item in a child-manifest object to any object in an ancestor Manifest.

B. An IdentifierRef child of a Dependency object:

i) Shall reference only a Resource that is a sibling of the Dependency’s parent Resource.

ii) Shall not reference the Dependency’s parent Resource.

iii) Shall not reference any object in a Manifest that is a child or ancestor of the Dependency’s immediately containing Manifest.

C. An IdentifierRef child of a Variant object:

i) Shall reference only a Resource or IPointer that is a sibling of the Variant’s parent Resource.

ii) Shall not reference the Variant’s parent Resource.

iii) Shall not reference any object in a Manifest that is a child or ancestor of the Variant’s immediately containing Manifest.

The scoping rules for manifests and (sub)manifests are shown in Figure 6.9.

 

Figure 6.9 - Scoping rules for manifests and (sub)manifests.

6.11.6 IsVisible class

Table 6.27 defines the IsVisible class in the IMS Content Packaging Information Model.

Table 6.27 IsVisible class definition.

 

 

 

Descriptor

Definition

Class name

IsVisible

Class type

Characteristic

Data type

Boolean

Value space

true (default)

false

Multiplicity

0..1

Parents

Item

Description

An IsVisible object signals a rendering process of whether to display a text string declared in a sibling Title object or to visually indicate the existence of an Item object in any other way.

No other behavior is imputed by this flag. There is no inheritance of visibility state declared by this IsVisible for any descendant Item of this IsVisible’s parent Item.

A value of “true” shall be the default value for IsVisible, even if it is not declared in a bound instance of an Item. That is, the absence of IsVisible for a parent Item is the same as if IsVisible with a value of “true” had been declared for the Item.

A value of “true” shall be interpreted to mean that the contents of a sibling Title should be displayed by a rendering application (i.e., Item{ IsVisible }.Title).

A value of “false” shall be interpreted to mean that the contents of a sibling Title should not be displayed by a rendering application (i.e., Item{ IsVisible }.Title).

6.11.7 Language class

Table 6.28 defines the Language class in the IMS Content Packaging Information Model.

Table 6.28 Language class definition.

 

 

 

Descriptor

Definition

Class name

Language

Class type

characteristic

Data type

string

Value space

The value space for the 1.3 Language element defined by IEEE 1484.12.1. The value space is defined by the following ABNF rules:

language-id = lang-code *lang-sub-code

; lang-code is any language code defined by ISO 639–1 & 2

lang-sub-code = "-" country-code

; country-code is any country code defined by

; ISO 3166-1

Multiplicity

1

Parents

LingualTitle

Description

A Language object identifies the human language of the string contained in the parent LingualTitle object.

6.11.8 LinkHref class

Table 6.29 defines the LinkHref class in the IMS Content Packaging Information Model.

Table 6.29 LinkHref class definition.

 

 

 

Descriptor

Definition

Class name

LinkHref

Class type

characteristic

Data type

URI

Value space

Binding language dependent. Constrained by the external referencing rules defined below.

Multiplicity

1

Parents

IPointer

Description

A LinkHref object unambiguously identifies a set of objects in a manifest, either in the same or a different (“remote”) manifest document.

A value declared for LinkHref shall be a syntactically valid absolute or relative reference. Because the URL has no location constraints, the scope of the characteristic is global.

6.11.9 LinkType class

Table 6.30 defines the LinkType class in the IMS Content Packaging Information Model.

Table 6.30 LinkType class definition.

 

 

 

Descriptor

Definition

Class name

LinkType

Class type

characteristic

Data type

string

Value space

Binding language dependent.

Multiplicity

0..1

Parents

IPointer

Description

A LinkType object provides a place to declare a term or keyword (e.g., a vocabulary word or phrase) to which special meaning has been assigned.

IMS Content Packaging shall use the “simple” keyword as a value for this object.

Linktype's scope is limited to its parent.

NOTE A simple link is a link that associates exactly two resources, one local and one remote, with an arc going from the former to the latter. Thus, a simple link is always an outbound link.

6.11.10 Other class

Table 6.31 defines the Other class in the IMS Content Packaging Information Model.

Table 6.31 Other class definition.

 

 

 

Descriptor

Definition

Class name

Other

Class type

characteristic

Data type

unknown to this Information Model

Value space

unknown to this Information Model

Multiplicity

0..unbounded

Parents

Manifest

Metadata

Organizations

Organization

Item

Resources

Resource

File

Dependency

Description

An Other object is an extension point for characteristics of a container class declared as the logical equivalents of characteristic classes.

Other is a placeholder. It informs bindings of this Information Model as to the valid locations for the introduction of characteristic classes that are defined by an information model other than this Information Model.

The actual name of an extending characteristic class type used in its place will be known only when a binding of that class is imported into a bound instance of this Information Model.

The semantics of any extending characteristic class shall stay within the scope of the semantics of a parent class per that class’s definition in this Information Model. The semantics of any extending characteristic class shall not override or redefine the semantics of any parent class defined in this Information Model.

The scope of Other is limited to its parent object.

6.11.11 Parameters class

Table 6.32 defines the Parameters class in the IMS Content Packaging Information Model.

Table 6.32 Parameters class definition.

 

 

 

Descriptor

Definition

Class name

Parameters

Class type

characteristic

Data type

string

Value space

See description below.

Multiplicity

0..1

Parents

Item

Description

A Parameters object provides a place to declare certain static, application-specific information that shall always be associated with an Item object. The parameters are not defined by this Information Model. Typically, the parameters are defined for use by an application that works with the information declared by an Item, including any files specified in any Resource object referenced by the Parameters’s parent Item.

The characters expressed as a value declared for a Parameters should be URI-encoded as defined in RFC3986.

The scope of Parameters is limited to its parent object.

6.11.12 Structure class

Table 6.33 defines the Structure class in the IMS Content Packaging Information Model.

Table 6.33 Structure class definition.

 

 

 

Descriptor

Definition

Class name

Structure

Class type

characteristic

Data type

string

Value space

See description below.

Multiplicity

0..1

Is extension point

false

Parents

Organization

Description

A Structure object describes the particular way that Item objects relate to each other within an Organization object. The scope of the Structure characteristic is limited to the parent Organization.

The value space for Structure includes terms approved by IMS Global Learning Consortium, Inc. and made available to the public in a controlled list [SDN11, 06]. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model.

The value space for Structure may be extended. Such extending expressions may be created and used only when no approved IMS value satisfies the expressive need of an implementing community to define the shape of a collection of Item objects in a given Organization.

Extending expressions used as a value for Structure shall follow the URI syntax rule defined in Section 3 of RFC3986. The syntax for terms extending the Structure value space shall disclose the source of a term as a URI and the term itself as a URI fragment: scheme://authority/hierarchy#term.

6.11.13 Type class

Table 6.34 defines the Type class in the IMS Content Packaging Information Model.

Table 6.34 Type class definition.

 

 

 

Descriptor

Definition

Class name

Type

Class type

characteristic

Data type

string

Value space

See description below.

Multiplicity

1..1

Parents

Resource

Description

A Type object provides a term, keyword, or phrase that indicates the type of resource being described by the parent Resource object.

The value space for Type includes the terms approved by IMS Global Learning Consortium, Inc. and made available to the public in a controlled list [SDN11, 06]. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model.

The value space for Type may be extended beyond that in the controlled list. Such extending expressions may be created and used only when no approved IMS value satisfies the expressive need of an implementing community.

Extending expressions used as a value for Type shall follow the URI syntax rule defined in Section 3 of RFC3986. The syntax for terms extending the Type value space shall disclose the source of a term as a URI and the term itself as a URI fragment: scheme://authority/hierarchy#term.

The scope of the Type characteristic is limited to the parent object. In particular, semantics expressed in a value for Type are not transmitted or “inherited” through the use of a Resource.Dependency{ IdentifierRef } reference.

6.11.14 Version class

Table 6.35 defines the Version class in the IMS Content Packaging Information Model.

Table 6.35 Version class definition.

 

 

 

Descriptor

Definition

Class name

Version

Class type

characteristic

Data type

string

Value space

repertoire of printable characters from [UCS]

Multiplicity

0..1

Parents

Manifest

Description

A Version object holds a value that signifies a distinctive version of a Manifest object. When this characteristic is declared for a Manifest that is a child of an InterchangePackage object, the value is the version of an IMS manifest document. When this characteristic is declared for any child-manifest, it is specific to that Manifest only and not to the entire document in which that child of Manifest resides.

A syntax for version information is not specified by this document. Implementers are allowed to use any syntactical representation that meets their needs.

The scope of Version is limited to its parent object.

Annex A Bibliography

(informative)

 

[CP, 07b]

IMS Content Packaging XML Binding Version 1.2 Public Draft 2.0, B. Nielsen, W. Kraan, J.Day and C.Smythe, IMS GLC, Inc., 2007. http://www.imsglobal.org/content/packaging/index.html

[CP, 07c]

IMS Content Packaging Best Practices and Implementation Guide Version 1.2 Public Draft 2.0, B. Nielsen, W. Kraan, J.Day and C.Smythe, IMS GLC, Inc., 2007. http://www.imsglobal.org/content/packaging/index.html

[VDEX, 04c]

IMS Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification, A. Cooper, IMS GLC, Inc., 2005. http://www.imsglobal.org/vdex/vdexv1p0/imsvdex_bestv1p0.html

[CP, 04a]

IMS Content Packaging Information Model v1.1.4, C.Smythe, A.Jackl, IMS GLC, Inc., October 2004. http://www.imsglobal.org/content/packaging/index.html

[CP, 04b]

IMS Content Packaging XML Binding v1.1.4, C.Smythe, A.Jackl, IMS GLC, Inc., October 2004. http://www.imsglobal.org/content/packaging/index.html

[SCORM, 04]

Sharable Content Object Reference Model (SCORM) 2004, second edition, Advanced Distributed Learning, July 2004.

 

About this document

 

the document properties

 

Title

IMS Content Packaging Information Model

Editors

Colin Smythe (IMS), Boyd Nielsen (Independent)

Co-chairs

Wilbert Kraan (JISC/CETIS), Jan Poston Day (Blackboard), Nigel Ward (DEST)

Version

v1.2 (Public Draft v2.0)

Version Date

01 March 2007

Status

Public Draft v2.0

Summary

This document describes the IMS Content Packaging v1.2 Information Model objects, their relationships, and purpose. It also defines selected behaviors of software components that create or process IMS content packages and IMS manifest documents.

Revision Information

04 December 2006

Purpose

This document is circulated for public comment. This document is the formal description of the IMS Content Packaging v1.2 Information Model. Organizations are encouraged to implement this version of the specification and to provide feedback on their experience.

Document Location

http://www.imsglobal.org/content/packaging/index.html

 

List of contributors

The following individuals contributed to the development of this document:

 

Name

Organization

Name

Organization

Martin Bayly

WebCT, Canada

Steve Hirst

Pearson Education, USA

Bill Bilic

WebCT, Canada

Scott Lewis

ADL, USA

Kerry Blinco

DEST, Australia

Wilbert Kraan

CETIS / JISC, UK

Jennifer Brooks

ADL, USA

Sheila MacNeill

CETIS / JISC, UK

Daniel Burgos

UNFOLD / OUNL, NL

Boyd Nielsen

Independent, USA

Adam Cooper

Tribal Technology, UK

Allyn Radford

HarvestRoad, Australia

Jan Poston Day

Blackboard, USA

Colin Smythe

IMS, UK

Philip Dodds

ADL, USA

Schawn Thropp

ADL, USA

Andy Heath

Independent, UK

Nigel Ward

DEST, Australia

Revision history

 

Version No.

Release Date

Comments

Final 1.0

25 May 2000

The initial release of the CP specification.

Final 1.1

19 April 2001

The first revision of the CP specification.

Final 1.1.1

23 May 2001

The first maintenance release of CP v1.1. There were no functional additions.

Final 1.1.2

08 August 2001

The second maintenance release of CP v1.1. There were no functional additions.

Final 1.1.3

12 June 2003

The third maintenance release of CP v1.1. There were no functional additions. The issues resolved were sourced from the IMS maintenance database.

Final 1.1.4

04 October 2004

The fourth maintenance release of CP v1.1. There were no functional additions. The issues resolved were sourced from the IMS maintenance database.

Public Draft 1.2
v1.0

21 November 2005

The initial v1.2 Public Draft version that was released to solicit initial feedback on the proposed changes in CP v1.2.

Internal Draft 1.2
v2.0

01 March 2007

The final v1.2 Internal Draft version that is issued to promote feedback of experience of implementation.

 

Index

B

Behavior 6, 40, 46

Best Practice Guide 6, 45

Binding 6, 8, 9, 10, 13, 14, 21, 22, 35, 36, 37, 38, 41, 42, 45

C

child-manifest 5, 8, 9, 13, 19, 26, 37, 38, 44

Conformance 6, 12

Content Package 5, 9, 10, 13, 46

control file 8, 9, 17, 19

CSS 8

E

Extension 6, 10, 12, 13, 14, 20, 21, 29, 30, 34, 35, 42, 43

I

IEEE 7, 40

IMS Specifications

Content Packaging 1, 5, 6, 9, 12, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 34, 35, 36, 37, 39, 40, 41, 42, 43, 44, 45, 46, 47

Vocabulary Definition Exchange 5, 45

imsmanifest 17

Information Model 1, 5, 6, 12, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 34, 35, 36, 37, 39, 40, 41, 42, 43, 44, 45, 46

interchange package 5, 8, 9, 10, 12, 22, 37

IPointer 18, 19, 20, 22, 24, 26, 28, 29, 30, 32, 33, 37, 38, 41

ISO 7, 40

L

launchable URI 8, 10, 28

Learning 5, 10

logical package 8, 9, 10, 13, 17, 19, 20

M

Manifest 8, 9, 10, 13, 14, 17, 21, 26, 28, 29, 32, 33, 36, 41, 44, 46

N

Namespace 6, 9, 12, 20, 30

Normative 14

P

package interchange file 8, 9, 17

package reader 8, 9, 12, 20, 21, 26, 37

package writer 10, 22

Profile 20, 21

R

reference 8, 9, 10, 13, 14, 17, 19, 26, 28, 29, 32, 36, 38, 41, 44

Resource 5, 8, 9, 10, 37, 44

Resources 5, 9, 10, 28, 41

S

Schema 8, 20

SCORM 2, 5, 11, 45

Standards 6

Structure 6, 9, 13, 14, 16, 20, 24, 26, 30, 36

U

URI 7, 8, 10, 11, 14, 17, 28, 35, 36, 37, 41, 42, 43, 44

V

variants 10

Vocabularies 5

Vocabulary 13, 41

W

W3C 2

X

XML 6, 8, 9, 11, 14, 17, 45

 




  1. Citations in brackets correspond to those in Section 2 and Annex A.

IMS Global Learning Consortium, Inc. (“IMS GLC”) is publishing the information contained in this document (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.
IMS GLC 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 GLC would appreciate receiving your comments and suggestions.
Please contact IMS GLC through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Content Packaging v1.2 Information Model Public Draft v2.0
Date: 1 March 2007