1EdTech Content Packaging Specification Primer Version 1.2 Public Draft v2.0

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 1EdTech Content Packaging Specification. The 1EdTech 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. 1EdTech 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 1EdTech 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 1EdTech Content Packaging Specification 5

1.2 Overview of the 1EdTech 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 1EdTech 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.

1EdTech Content Packaging is such a content format agreement.

1.2 Overview of the 1EdTech Content Packaging Specification

1EdTech 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 1EdTech content package and how it is structured, such as a table of contents or which HTML page to show first.

The 1EdTech 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 1EdTech formats, such as Question and Test Interoperability items or 1EdTech Learner Information Packaging fragments. However, using such resources requires specialized tools beyond an LMS that implements just an 1EdTech 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, 1EdTech 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 1EdTech Content Packaging.

The documentation set for 1EdTech 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 1EdTech 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

3. Acronyms and abbreviations

4. Content packages and content packaging

Functionally, 1EdTech 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 1EdTech 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, 1EdTech 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 1EdTech 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 1EdTech Content Packaging Specification clarifies and regularizes the behavior of software components that are engaged in the creation of 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech manifest only may be exchanged – all assets referenced within it (or other 1EdTech 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. 1EdTech 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 1EdTech 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 1EdTech Content Packaging. The version 1.2 project group went to some effort to provide for the future growth and adaptability of 1EdTech Content Packaging to emerging or yet-to-be-defined needs of adopters, while preserving the flexible framework that is an 1EdTech 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 1EdTech Content Packaging and the proliferation of hundreds of thousands of 1EdTech 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 1EdTech Content Packaging without affecting the existing 1EdTech 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, 1EdTech 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 1EdTech 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, 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Packaging and guidelines for making them. These include, respectively, 1EdTech’ own Common Cartridge and the 1EdTech Application Profile Guidelines. While communities with an interest in profiling 1EdTech Content Packaging for their own purposes are advised to consult both the 1EdTech guidelines and many others that exist on the subject, some pointers can be given here.

Profiling 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Packaging itself provides, but more specific types of data that are aggregated by packages. Examples include Learner Information Profile documents and 1EdTech 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, 1EdTech 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 1EdTech Content Packaging Specification Primer (this document) is to provide a brief description of the full 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Content Packaging XML Binding [CP, 07b] describes the realization of the Information Model in XML. The Binding document uses the 1EdTech 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 1EdTech 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 1EdTech Content Packaging Best Practice and Implementation Guide [CP, 07c] is intended to provide vendors with an overall understanding of the 1EdTech Content Packaging Specification, the relationship of the specification with other 1EdTech specifications, and a best practices guide derived from experiences of those using the specification.¹ The guide also includes a several actual examples that describe how vendors can make the best use of the 1EdTech 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:

• 1EdTech 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];

• 1EdTech 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];

• 1EdTech 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 1EdTech 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 1EdTech content packages.

• The VDEX XSD that is used to validate the VDEX instances that contain the 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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

List of contributors

The following individuals contributed to the development of this document:

Revision history

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

1EdTech 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 1EdTech Content Packaging Specification start with the 1EdTech 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.