IMS Logo

IMS Content Packaging Specification Primer


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 Specification Primer 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,” is either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

“W3C,” “HTTP” and “XML” are registered trademarks or trademarks 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.

Overview

This primer provides a basic introduction to the IMS Content Packaging Specification. The IMS Content Packaging specification describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content. IMS content packages enable exporting content from one learning content management system or digital repository and importing it into another while retaining information describing the media in the content package and how it is structured, such as a table of contents or which web page to show first. The IMS Content Packaging Specification focuses on the packaging and transport of resources but doesn’t determine the nature of those resources. This is because the specification allows adopters to gather, structure, and aggregate content in an unlimited variety of formats.

 

Table of contents

Intellectual property acknowledgements 2

Overview 3

1. Introduction 5

1.1 Context for the IMS Content Packaging Specification 5

1.2 Overview of the IMS Content Packaging Specification 5

1.3 Structure of this document 6

2. References 7

3. Acronyms and abbreviations 8

4. Content packages and content packaging 9

5. The historic perspective 10

5.1 Past versions 10

5.2 A summary of changes from version 1.1 10

6. Using the new version 11

6.1 Packaging learning material 11

6.2 Types of packages 12

6.2.1 The simple stand-alone package 12

6.2.2 The bare manifest 12

6.2.3 The composite or meta-package 12

6.2.4 The archive package 13

6.2.5 Specialized packages 13

6.3 Creating an application profile of a content package 13

7. The document set 14

7.1 The set of documents 14

7.1.1 Primer 14

7.1.2 Information Model 14

7.1.3 XML Binding 14

7.1.4 Best Practice and Implementation Guide 14

7.1.5 Related documents 14

7.2 The XSD, vocabularies, and examples 15

7.3 Using the documents 15

About this document 16

List of contributors 16

Revision history 17

Index 18

 

1. Introduction

1.1 Context for the IMS Content Packaging Specification

People want to share e-learning content for a variety of reasons. Educators may want to share useful lessons with colleagues, publishers want to sell content, and communities of practice want to pool resources to reduce the costs of creating effective learning content. All of these scenarios presuppose that content can be exchanged freely without technical barriers.

In addition, it is desirable to have a variety of tools to help with the creation, management, and playback of e-learning content. Different people may have different requirements for each of these types of tools. For example, price may be more important than user-friendliness for some. What’s more, such requirements may change over time, which means that the same content should work with tools that may not have been developed yet.

To enable sharing of content and to give people a choice of content creation, management, and playback tools, it is necessary to agree on a content format. Such a format means that, for example, content can be authored without worrying about which learning content management system (LCMS) will be used at any given point in a content object’s lifetime.

IMS Content Packaging is such a content format agreement.

1.2 Overview of the IMS Content Packaging Specification

IMS Content Packaging describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content. The specification enables exporting content from one LMS or digital repository and importing it into another while retaining information that describes the media in the IMS content package and how it is structured, such as a table of contents or which HTML page to show first.

The IMS Content Packaging Specification focuses on the packaging and transport of resources, but doesn’t determine the nature of those resources. The specification allows adopters to gather, structure, and aggregate content in an unlimited variety of formats. A typical content package consists of Web pages and common picture formats, such as JPEGs. Other packages may contain more specialized material such as Java applets or other IMS formats, such as Question and Test Interoperability items or IMS Learner Information Packaging fragments. However, using such resources requires specialized tools beyond an LMS that implements just an IMS content package.

The central part of a content package is the manifest. A manifest describes the logical package and the relationships among all of its components. The manifest is both an XML document, and, more abstractly, the structural information in that document. Within the manifest, the resources section functions as a bill of materials. It lists all files that are contained in the interchange package and all references to resources that reside elsewhere. In certain cases, it may also contain specialized structural content in the resources section of the manifest document itself. Finally, the organization section of the manifest structures all of the content package’s components into a piece of educational content.

Prior to the current work, IMS Content Packaging version 1.1 was the most recent major functional revision, completed in April 2001. Since then, many requests have been made for mostly minor functional additions and corrections, resulting in the version 1.1.x series of this specification. Requests for a few major additions were allowed to accumulate as practice matured around implementing IMS Content Packaging.

The documentation set for IMS Content Packaging can appear to be daunting. However, a few simple guidelines make it relatively easy for even a newcomer to work through the documents:

a) Start with the primer (this document).

b) Read the IMS Content Packaging Best Practice and Implementation Guide [CP, 07c] before attempting to work through either the Information Model [CP, 07a] or the XML Binding [CP, 07b].

c) Once the set of examples in the Best Practice Guide has been digested, work through the Information Model.

d) Finally, work through the XML Binding. (Often, only the implementation/engineering team needs to understand the details of this document.)

1.3 Structure of this document

The structure of the rest of this document is:

 

2. References

Lists references to other standards and specifications cited in this document;

3. Acronyms and Abbreviations

Includes expanded acronyms and abbreviations used in this document;

4. Content Packages & Content Packaging

Explains the basic structure of an IMS content package and describes the different types of content packages that may be created using this specification;

5. The Historic Perspective

Provides the historic context for the specification. This includes a summary of the changes between versions 1.1 and 1.2;

6. Using this New Version

Provides an overview of the various ways in which this specification can be used to create different content package instances;

7. The Document Set

Lists and explains the set of documents produced as a part of the specification. This includes an explanation of the relevant IMS Specification Development Notes (SDNs).

2. References

 

[CP, 07a]

IMS Content Packaging Information Model v1.2 Public Draft v2.0, C.Smythe, B.Nielsen, IMS GLC, Inc., March 2007. http://www.imsglobal.org/content/packaging/

[CP, 07b]

IMS Content Packaging XML Binding v1.2 Public Draft 2.0, C.Smythe, B.Nielsen, IMS GLC, Inc., March 2007. http://www.imsglobal.org/content/packaging/

[CP, 07c]

IMS Content Packaging Best Practice and Implementation Guide v1.2 Public Draft 2.0, C.Smythe, B.Nielsen, IMS GLC, Inc., 2007. http://www.imsglobal.org/content/packaging/

[SDN07, 06]

UML Profile for Platform Independent Model Descriptions of Specifications, SDN-07, C.Smythe, IMS GLC, Inc., October 2006.

[SDN08, 06]

UML Profile for Platform Specific Model Descriptions of Specification Bindings, SDN-08, C.Smythe, IMS GLC, Inc., October 2006.

[SDN11, 06]

Vocabulary Definitions, Registration and Maintenance Procedures, SDN-11, C.Smythe, IMS GLC, Inc., July 2006.

[VDEX, 04]

IMS Vocabulary Definition Exchange Information Model v1.0, A.Cooper, IMS GLC, Inc., February 2004. http://www.imsglobal.org/vdex/

3. Acronyms and abbreviations

 

 

 

HTML

Hypertext Mark-up Language

IEEE

Institute of Electrical and Electronics Engineers

ISO

Organization for Standardization

JPEG

Joint Picture Encoding Group

LCMS

Learning Content Management System

LMS

Learning Management System

PIM

Platform Independent Model

PSM

Platform Specific Model

SCORM

Sharable Content Object Reference Model

SDN

Specification Development Note

UML

Unified Modelling Language

VDEX

Vocabulary Definition Exchange

W3C

World-wide Web Consortium

XML

Extensible Mark-up Language

XSD

XML Schema Definition

4. Content packages and content packaging

Functionally, IMS Content Packaging sits between the authoring and playback of basic components, such as HTML pages, and the content management processes of a digital repository or LCMS. For that reason, the heart of IMS Content Packaging consists of a few related, fundamental, content-aggregation concepts. These concepts capture the need to scope, gather, describe, list, and structure the components that make up a content package.

At the top of the aggregation tree, the logical package includes all the components of the content package, regardless of whether they are local or remote, or whether they are referred to directly or indirectly. In other words, the logical package defines the scope of a content package.

Next is the interchange package, which is the collection of components (i.e., files, at this level) that can be exchanged. The form (e.g., ZIP, CD–ROM, etc.) is not defined, but an interchange package needs to have some type of file-system representation. This is typically a ZIP archive, but a CD–ROM or a folder on a network drive is also possible. The interchange package can, but doesn’t have to, physically contain all of the components scoped by the logical package.

The central part of the content package is the manifest. The manifest describes the logical package and the relationships among all of its components. The manifest is both an XML document, and, more abstractly, the structural information in that document.

Within the manifest, the resources section functions as a bill of materials. It lists all the files that are contained in the interchange package and all references to resources that reside elsewhere. In certain cases, it may also contain specialized structural content in the resources section of the manifest document itself.

Finally, the organization section of the manifest structures all of the logical package’s components into a piece of educational content. The organization section describes the static relationships between the different resources, and can also contain instructions for dynamic and interactive learning activities.

5. The historic perspective

5.1 Past versions

Prior to the current work, IMS Content Packaging version 1.1 was the most recent major functional revision, completed in April 2001. Since then, requests have been made for mostly minor functional additions and corrections, resulting in the version 1.1.x series of this specification. Requests for a few major additions were allowed to accumulate as practice matured around implementing IMS Content Packaging.

5.2 A summary of changes from version 1.1

Major functional changes from version 1.1 up to and including 1.1.4 consist of:

• Separation of control documents (XSDs) from the Information Model document.

• Clarifications of the use of child manifests;

• ‘xml:’ prefix recommendation – adoption of the W3C ‘xml.xsd’ file for the definition of the ‘xml:’ name-spaced attributes available to the content package. This makes newer packages easier to validate with modern tools.

• parameter attribute vocabulary – adoption of a syntax for the definition of parameters as contained in the parameter attribute plus definition of the algorithm to construct an associated URI.

• Href filename format recommendation – formal definition of the file name formats that must be adopted when using the Href attribute.

• ZIP file format recommendation – formal definition of the ZIP file format that shall be adopted for interchange packages that are ZIP archive based.

• Name-spacing of xml:lang made consistent.

• Clarification of the scoping of meta-data in a content package.

• Clarified the usage of local and remote XSDs for instance validation.

• Improved guidance on merging submanifests. This is an intricate operation that may be best replicated using the newer ipointer mechanism.

• Clarified submanifest referencing using the <dependency> element.

• Requirement to declare all files in a content package’s manifest.

In addition, the various versions contain many more clarifications and some corrections. Apart from a completely new documentation set, the main functional changes from version 1.1.4 and 1.2 are:

• Bringing the Binding into line with the Information Model such that the schema and schemaversion elements can only refer to the whole package.

• New mechanism to extend and register resource type values.

• New mechanism to extend and register organization type values.

• The <variant> element to enable package authors to point to alternative resources.

• New mechanism to refer to remote manifest structures and include them in the base manifest.

6. Using the new version

6.1 Packaging learning material

Version 1.2 (this version) of the widely adopted IMS Content Packaging Specification clarifies and regularizes the behavior of software components that are engaged in the creation of IMS content packages and harvesting the information contained within them. These software components are generally referred to as package writers and package readers.

The information held in IMS content packages is often stored in enterprise-scale repositories. A high degree of interest exists in re-using information objects as well as their order and sequence. This kind of re-usability can leverage proven structures, apply known information in novel ways, or simply lower costs of knowledge and skill acquisition.

Earlier versions of the IMS Content Packaging Specification focused almost exclusively on exchanging physical files, especially a special–purpose, compressed, binary file called a package interchange file. This version continues to support that approach, but also broadens the exchange of information to exchanging a logical package rather than a physical one. That is, an IMS manifest only may be exchanged – all assets referenced within it (or other IMS manifests to which it might be linked) remain in their known storage locations and are used from those systems. Logical packages dramatically reduce costs for all parties concerned in terms of storage, maintenance, and payload pushed “across the wire.” This, in turn, should greatly facilitate and accelerate the provision of information to areas in which it is best applied.

An interest is also growing in tailoring the presentation of information to a given profile, needs, or requirements of a given individual or groups of individuals. This often involves wide varieties of the same information expressed in different formats or presentation modalities. Version 1.2 makes it possible to relate assets that support such varied and richly adaptable requirements. The approach relies heavily on an emerging consensus around how best to define such requirements and describe the assets enabling them in meta-data.

Meta-data is key to the discovery and use of information expressed in terms of references to physical artifacts, both digital and non-digital. Version 1.2 heals a long-running issue in terms of its approach to modelling meta-data and binding the data structures used to convey it. IMS Content Packaging v1.1.3 and v1.1.4 both defined specific object models for expressing meta-data, which unfortunately were not faithfully bound as data structures. This split between the definition in the Information Model and the model’s realization in XML Schema data structures has caused some confusion among adopters of IMS Content Packaging.

Version 1.2 addresses this issue by declaring the original meaning normative, and the laxity of the previous bindings tolerated (i.e., the binding allows the use of schema and schemaversion to indicate meta-data control files, even if developers should not author packages in this way.)

Stability is also important for a key specification, such as IMS Content Packaging. The version 1.2 project group went to some effort to provide for the future growth and adaptability of IMS Content Packaging to emerging or yet-to-be-defined needs of adopters, while preserving the flexible framework that is an IMS manifest. The team has accomplished this by separating the lists of vocabulary terms used by certain object classes in the Information Model from the model itself. These terms are defined and approved in a separate maintenance process that does not require a revision of the specification just to accommodate new terms.

Similarly, given the widespread adoption of IMS Content Packaging and the proliferation of hundreds of thousands of IMS content packages, it is important that existing software components continue to process content packages they were designed to handle and that new software components conforming to version 1.2 also process the older content packages as designed. Newer systems will also honor the new extension object classes that enable the linking and referencing behaviors desired by enterprise scale users. The new classes are defined in a separate namespace that leverages the extension points and semantics of IMS Content Packaging without affecting the existing IMS Content Packaging namespace. The best of the past is preserved as it provides a strong foundation for future growth without having to alter its structural integrity.

Throughout the development process, the project group has expended effort to use proven technologies defined by trusted organizations such as the World Wide Web Consortium (W3C), the Institute of Electrical and Electronics Engineers (IEEE) Learning Technologies Standards Committee, and the International Organization for Standardization (ISO), among several others. The team hopes that by adopting the technologies and vetted techniques of such organizations, IMS Content Packaging will have a secure and thriving future to benefit all adopters, but most importantly, the learners for whom all this interoperability activity is focused.

6.2 Types of packages

As the use of IMS Content Packaging has grown over the years, several general types of packages have emerged. Depending on community requirements and processes, commonly found packages tend to look like instances of one of the following stereotypes.

6.2.1 The simple stand-alone package

Using a ZIP archive for its interchange format, this package type typically includes all of its resources in the interchange file. For simplicity, it has only one level of manifest; no child manifests are included. A couple of organizations tend to be included, usually to provide an alternative to the default organization in a different language or to meet some other access requirement.

Content packages that conform with the most popular content packaging profile, the Sharable Content Object Reference Model (SCORM), also typically follow the simple stand-alone pattern. Where they differ from packages that follow other profiles is in the inclusion of meta-data. SCORM packages need to have package-level meta-data in a separate file that is linked to from the manifest. Other profiles typically include package-level meta-data inline in the manifest itself. Other differences include the support SCORM packages have for learner-to-content interaction tracking and, in SCORM 2004, IMS Simple Sequencing.

Content packages of the simple, stand-alone type are likely to be most widely supported in various LMSs, and therefore, to be the most robust in interoperability.

6.2.2 The bare manifest

This package type does not include all resources in the interchange file. Instead, it references them via links to a known repository. Depending on the implementation, a bare manifest package can be interchanged using either just the manifest file, or the manifest file as the sole content of a ZIP archive or other interchange file.

The advantages of using this package type include:

• The exact same resources can be re-used many times.

• Resources can be updated at any time.

• Resources can be tracked easily by the publisher or repository owner.

• Access to resources can be controlled easily and precisely by the publisher or repository owner.

The main disadvantage of this type of package is the fact that the LMS needs to have reliable access to all resource repositories.

6.2.3 The composite or meta-package

This package type takes the bare manifest type one step further by linking to other entire packages rather than just conventional resources, such as Web pages. Various patterns of aggregating packages and resources are conceivable using this package type, but it is expected that a popular pattern will be of the relatively thin package that aggregates little beyond references to a set of complete, relatively self-contained packages, similar to how a number of lectures can constitute a course.

The main advantage of the composite package is that it takes re-usability of structured content a significant step beyond other types of packages. The disadvantage is that the functionality that enables this package type is comparatively new, which means that not every package reader will be able to support all the functionality.

6.2.4 The archive package

This common package type is not intended for presentation to a learner. Instead, it is used to store resources and definitions of their basic structures for future use. Archive packages do not have an organization section, only a resource section.

This package type is typically used to exchange raw content files that can be turned into finished packages later.

6.2.5 Specialized packages

Specialized packages do not conform to a particular common pattern, but are similar in that they are used to convey very specific types of content, often inline, in the manifest. Most of these packages are combinations of packages with content defined in other IMS specification, such as ePortfolios, Question and Test Interoperability items, and Learning Design Units of Learning.

In each case, a significant part of the content that is described in the manifest is neither an external file nor a structure that conforms to Content Packaging itself. Instead, the core of these packages is the description of specific data in an XML dialect, and IMS Content Packaging merely provides a convenient way of aggregating such descriptions.

6.3 Creating an application profile of a content package

Over the years, various communities have produced both excellent application profiles of IMS Content Packaging and guidelines for making them. These include, respectively, IMS’ own Common Cartridge and the IMS Application Profile Guidelines. While communities with an interest in profiling IMS Content Packaging for their own purposes are advised to consult both the IMS guidelines and many others that exist on the subject, some pointers can be given here.

Profiling IMS Content Packaging version 1.2 has essentially two dimensions: one is the limitation of multiplicity in the specification; another is the addition of specialized structures at one of the specification’s many extension points.

The first dimension can also be called proper profiling in that it commits developers to fewer choices than the full specification allows. Common examples include the proscription of child manifests and the prescription of a particular meta-data schema.

The extension of IMS Content Packaging is possible at virtually any level of the logical package. In the case of extensions to the organization section, both the existing structure can be extended (as SCORM does) and an organization can be replaced by a wholly different type of structure, such as an ISO TopicMap. In the latter case, it is advisable to provide a conventional organization alongside the alternative structure in order to ensure maximum interoperability with minimal semantic loss. People are also encouraged to submit alternative organization structures to IMS for registration, so that developers can easily find out about them.

Much the same goes for extensions to the resources section of the manifest. These extensions are not usually outright replacements for the structures that IMS Content Packaging itself provides, but more specific types of data that are aggregated by packages. Examples include Learner Information Profile documents and IMS Question and Test Interoperability items that are included inline. It is vitally important for a package processing application (e.g., an LMS) to know about the nature of such resources in order to handle them correctly. For that reason, IMS has set up a procedure to describe and submit new resource type values and flag them in the manifest.

7. The document set

7.1 The set of documents

7.1.1 Primer

The role of the IMS Content Packaging Specification Primer (this document) is to provide a brief description of the full IMS Content Packaging Specification. This is the only document that brings together all of the other documents to provide a perspective on the full specification.

7.1.2 Information Model

The IMS Content Packaging Information Model Specification [CP, 07a] is the normative description of the content package data structures and their relationships. This description uses the Unified Modelling Language (UML), and in particular, the IMS UML Profile Platform Independent Model (PIM) Description for Specifications [SDN07, 06]. The Information Model document also contains conformance statements against which an implementation must comply. It also describes the core content package functionality plus the extensions that are introduced in version 2.1 (the new functionality is expressed as extensions to the core).

7.1.3 XML Binding

The IMS Content Packaging XML Binding [CP, 07b] describes the realization of the Information Model in XML. The Binding document uses the IMS UML Profile for Platform Specific Model (PSM) Descriptions of Specification Bindings [SDN08, 06]. This PSM has been transformed into the corresponding XML Schema Definition (XSD) files using the IMS Binding Autogeneration Toolkit. The Binding is realized as two XSDs, the core content package XSD file “imscp_v1p2.xsd” and the extension functionality in the XSD file “imscp_extensionv1p2.xsd”. The Binding document describes the underlying structure of the XSD and the formats of the corresponding instances of a content package.

7.1.4 Best Practice and Implementation Guide

The IMS Content Packaging Best Practice and Implementation Guide [CP, 07c] is intended to provide vendors with an overall understanding of the IMS Content Packaging Specification, the relationship of the specification with other IMS specifications, and a best practices guide derived from experiences of those using the specification.1 The guide also includes a several actual examples that describe how vendors can make the best use of the IMS Content Packaging Specification. These examples are also useful as a starting template for each of the different forms of content packages.

7.1.5 Related documents

The following related documents were used to support the development of this specification:

• IMS GLC SDN 07: UML Profile for PIM Descriptions of Specifications [SDN07, 06] – provides the definition and description of the syntax and semantic of the UML profile used for the PIM description of the information model [CP, 07a];

• IMS GLC SDN 08: UML Profile for PSM Descriptions of Specification Bindings [SDN08, 06] – provides the definition and description of the syntax and semantics of the UML profile used for the PSM description of the XML Binding [CP, 07b];

• IMS GLC SDN 11: Vocabulary Definition, Registration and Maintenance Procedures [SDN11, 06] – provides the definition and description of how the ‘structure’ and resourceType’ attribute vocabularies are expressed as instances of the IMS Vocabulary Definition Exchange (VDEX) specification [VDEX, 04].

7.2 The XSD, vocabularies, and examples

The written documents are accompanied by a set of XSDs and XML instances. Several XSDs are included:

• The two XSDs that are used to validate version 1.2 IMS content packages.

• The VDEX XSD that is used to validate the VDEX instances that contain the IMS Content Packaging vocabularies.

• The IEEE Learning Object Metadata XSDs that are used to validate the meta-data contained within the vocabulary instances.

Two vocabulary files are supplied:

• imscp_structurevocabv1p0.xml – the vocabulary of the default set of types of organization structure.

• imscp_restypevocabv1.0.xml – the vocabulary of the default set of resource types.

These vocabularies are instances of the IMS VDEX specification.

Finally, a set of examples is supplied. These examples, which are XML instances of a content package manifest, demonstrate all of the key features of the IMS Content Packaging Specification. These instances can also be used as templates for producing other content package manifests.

7.3 Using the documents

The documentation set of the IMS Content Packaging Specification can appear to be daunting. However, a few simple guidelines make it relatively easy for even a newcomer to work through the documents:

a) Always start with the primer (this document).

b) The IMS Content Packaging Best Practices & Implementation Guide is an excellent way to understand the why, what, and how of a specification. The set of examples described in the guide is an excellent way to understand what is being created by the specification. The guide should always be read before attempting to work through either the Information Model or the XML Binding.

c) Once the set of examples has been digested, it is time to work through the Information Model. This model provides the formal definition of all of the data structures and their relationships. In most cases it is easy to spot how the data structures are realized in the examples.

d) Finally, work through the XML Binding document. Often, only the implementation/engineering team needs to understand the details of this document. This document is the definitive statement of how interoperability is achieved using XML. The Binding is formally realized as the XSD files. These files are used to validate the XML instances. (In this case those instances are the manifest files for a content package.)

About this document

 

the document properties

 

Title

IMS Content Packaging Specification Primer

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 Primer provides an overview of the IMS Content Packaging specification. It provides an overview of the specification, explains how to use the specification documentation and sets the context for the specification as a whole.

Revision Information

04 December 2006

Purpose

This document is circulated for public comment. This document should be used to introduce the IMS Content Packaging v1.2 specification. 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

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

A

Aggregation 9

B

Behavior 11

Best Practice Guide 5, 7, 14, 15

Binding 5, 6, 7, 10, 11, 14, 15

C

Conformance 14

Content Package 3, 5, 6, 9, 10, 11, 13, 14, 15

control file 11

E

Extension 11, 13, 14

H

HTTP 2

I

IEEE 8, 11, 15

IMS Specifications

Content Packaging 1, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17

Question and Test Interoperabili­ty 5, 13

Vocabulary Definition Exchange 7, 8, 14, 15

Information Model 7, 14

interchange package 5, 9, 10

Interoperability 12, 13, 15

IPointer 10

ISO 8, 12, 13

L

Learning 3, 5, 9, 11

LMS 5, 8, 12, 13

logical package 5, 9, 11, 13

M

Manifest 5, 9, 10, 11, 12, 13, 15

Meta-data 10, 11, 12, 13, 15

N

Namespace 11

Normative 11, 14

P

package interchange file 11

package reader 11, 12

package writer 11

Profile 11, 12, 13, 14

R

Repositories 11, 12

Resource 10, 12, 13, 15

Resources 3, 5, 9, 10, 12, 13

S

Schema 10, 11, 13

SCORM 2, 8, 12, 13

Sequencing 12

Standards 6

Structure 3, 5, 6, 9, 13, 14, 15

U

URI 10

V

Validation 10

Vocabularies 14, 15

Vocabulary 10, 11, 15

W

W3C 2, 8, 10, 11

X

XML 2, 5, 6, 7, 8, 9, 11, 13, 14, 15

XSD 8, 14, 15

 




  1. We recommend that new users of the IMS Content Packaging Specification start with the IMS Content Packaging Best Practices & Imple­mentation Guide. The examples in this document show how we intend the specification to be used, whereas the Information Model and XML Binding documents contain the formal description of the structures, their syntax and semantics.

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 Primer Public Draft v2.0
Date: 1 March 2007