ISO/IEC TR 12785-3:2012

TECHNICAL ISO/IEC
REPORT TR
12785-3
First edition
2012-05-01


Information technology — Learning,
education, and training — Content
packaging —
Part 3:
Best practice and implementation guide
Technologies de l'information — Apprentissage, éducation et
formation — Paquetage du contenu —
Partie 3: Meilleure pratique et guide de mise en application




Reference number
ISO/IEC TR 12785-3:2012(E)
©
ISO/IEC 2012

---------------------- Page: 1 ----------------------
ISO/IEC TR 12785-3:2012(E)

COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2012 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC TR 12785-3:2012(E)
Contents Page
Foreword . iv
0. Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Using content packages — Use cases and practices . 4
5.1 Typical practice . 4
5.2 Keeping control over resources after a package has been published . 5
5.3 Aggregate content at an appropriate level of granularity . 6
5.4 Specialized packages with combination of various specifications . 8
5.5 Working with child-manifests and applying IMS simple sequencing rules using the new
IPointer mechanism . 9
5.6 Packaging METS and other complex object encodings . 10
5.7 Using alternative organization structures, such as topic maps . 12
5.8 Working with alternative resources . 13
5.9 Avoiding repeated lists of the same assets for different resources . 15
5.10 Working with local and global identifiers . 17
5.11 Support for multiple languages in titles . 17
Annex A (informative)  Document provenance . 19
Annex B (informative) Intellectual property acknowledgements . 20
Bibliography . 21

© ISO/IEC 2012 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC TR 12785-3:2012(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when the joint technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may decide to
publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review
every five years in the same manner as an International Standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 12785-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 36, Information technology for learning, education and training.
ISO/IEC 12785 consists of the following parts, under the general title Information technology — Learning,
education, and training — Content packaging:
 Part 1: Information model
 Part 2: XML binding
 Part 3: Best practice and implementation guide [Technical Report]

iv © ISO/IEC 2012 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC TR 12785-3:2012(E)
0. Introduction
0.1 Purpose and overview
The primary focus of this part of ISO/IEC 12785 is on sharing existing best practice and providing suggested
practice for implementing the functionality included in this part of ISO/IEC 12785. The ISO/IEC 12785 series
has been commonly used in the learning, education, and training (LET) domain and this part of
ISO/IEC 12785 is intended to support this use. It focuses on the construction of instances of manifest
documents and the content packages they define.
0.2 Compatibility
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 the ISO/IEC 12785
series also process the older IMS content packages as designed. Newer systems will need the ability to
)
1
process the new extension objects introduced in the ISO/IEC 12785 series that enable linking and
referencing behaviors. The functionality of these new extension objects are described in Clause 5 of this part
of ISO/IEC 12785, and normative descriptions are contained in ISO/IEC 12785-1.
The new extension objects are defined in a separate namespace that leverages the extension points and
semantics of the ISO/IEC 12785 series without affecting the existing IMS Content Packaging namespace.
ISO/IEC 12785 also separates the lists of vocabulary terms used by certain objects in the information model
(and a dedicated new namespace) from the model itself. These details are contained in the IMS GLC
Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures.
By taking this approach, we hope that the best of the past is preserved as it provides a strong foundation for
future growth without having to alter the structural integrity of the ISO/IEC 12785-1 information model (a
detailed, normative description of backwards and forwards compatibility is contained in ISO/IEC 12785-1).


1) The extension refers to those elements that have been newly introduced with IMS Content Packaging version 1.2
which is a source of ISO/IEC 12785.
© ISO/IEC 2012 – All rights reserved v

---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 12785-3:2012(E)

Information technology — Learning, education, and training —
Content packaging
Part 3:
Best practice and implementation guide
1 Scope
This part of ISO/IEC 12785 presents use cases and shows how they are satisfied by ISO/IEC 12785-1 which
is derived from the IMS Global Learning Consortium (GLC) Content Packaging version 1.2 (v1.2).
Though not exhaustive, the range of use cases presented in this part of ISO/IEC 12785 illustrate how the most
common issues in the creation, management, and playback of learning material can be addressed by the
ISO/IEC 12785 series. The use cases were contributed by various implementers and users of the IMS
Content Packaging and are based on years of practice.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated reference, the latest edition of the referenced document
(including any amendments) applies.
ISO/IEC 12785-1:2009, Information technology — Learning, education, and training — Content packaging —
Part 1: Information model
IETF RFC 1951 (1996), DEFLATE Compressed Data Format Specification version 1.3
3 Terms and definitions
For purposes of this document, the following terms and definitions apply.
3.1
child manifest
complete, subordinate manifest contained in or referenced by the parent manifest
NOTE 1 According to IMS Content Packaging version 1.2 (and ISO/IEC 12785-1), a manifest can contain more than
one child manifest.
NOTE 2 A manifest can include a reference to a child manifest that is external to the interchange package.
NOTE 3 A child manifest describes a complete logical package that is part of the larger logical package defined by its
parent manifest.
NOTE 4 A child manifest can be local or remote.
Adapted from ISO/IEC 12785-1:2009.
© ISO/IEC 2012 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC TR 12785-3:2012(E)
3.2
content
individual file or multiple files usable in learning, education and training
NOTE 1 A logical unit of usable (and reusable) information can be described by a logical package.
NOTE 2 A logical package can contain one or more units of content.
3.3
content file
collection of files, including at least one manifest file, and conforming to the ISO/IEC 12785-1 information
model and the ISO/IEC 12785-2 XML binding
NOTE Content files can be local or remote.
3.4
control file
single computer file that governs the binding of the Content Packaging Information Model (CPIM) to make it
suitable for machine processing
NOTE A software component can 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 can be used as a control file for an XML binding of a manifest.
[ISO/IEC 12785-1:2009, 3.4]
3.5
interchange package
set of usable (reusable) LET content that is exchanged among computing systems used for information
technology for learning, education and training (ITLET) purposes
NOTE An interchange package can 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).
[ISO/IEC 12785-1:2009, 3.5]
3.6
manifest
description of files and any logical relationships between them, contained or referenced in a content package
3.7
metadata
content packaging descriptive information about logical packages, logical organizations, content, and files
NOTE 1 Metadata can be assigned to any of the components within the logical package including the manifest.
NOTE 2 Any binding of a metadata object is permitted. Each object of metadata can be local or remote.
[ISO/IEC 12785-1:2009, 3.12]
3.8
namespace
XML namespace identified by a URI reference
NOTE Namespace in Content Packaging follows W3C recommendation, Namespaces in XML 1.0 (Second Edition).
[ISO/IEC 12785-1:2009, 3.13]
2 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC TR 12785-3:2012(E)
3.9
organization
logical relationships, such as a hierarchical tree, among a unit of content
NOTE More than one logical organization can be described in a manifest.
3.10
package
unit of usable (and reusable) LET content
NOTE 1 This can be part of a learning course that has instructional relevance outside of a LET content aggregation
and can be delivered independently, as an entire learning course or as a collection of learning courses.
NOTE 2 A package is able to stand-alone, that is, it contains all the information needed to use the contents for learning,
education, and training when it has been unpacked.
[ISO/IEC 12785-1:2009, 3.14]
3.11
package reader
software that processes an interchange package by checking statements in the manifest against
corresponding contents and organization
NOTE 1 A package reader can process both logical and physical packages.
NOTE 2 The term “process” may include the retrieval and storage of information referenced by the manifest, the
decompression or unpacking of local files from a PIF, and the retrieval and/or logging of addresses of remote files
3.12
package writer
software that creates or modifies an instance of an interchange package and assembles content file(s) 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 typed process
[ISO/IEC 12785-1:2009, 3.17]
3.13
package interchange file
PIF
instantiation of an interchange package which is physically encapsulated as a compressed binary file
conforming to IETF RFC 1951 (1996)
NOTE 1 An interchange package may be instantiated in a format other than a package interchange file (PIF).
NOTE 2 The representation (binding) is usually expressed in XML.
EXAMPLE An interchange package can be instantiated as a collection of files on removable media, e.g. CD, DVD,
USB memory device, or compressed using another format such as .zip, .tar, .jar, .cab.
[ISO/IEC 12785-1:2009, 3.15]
3.14
resource (in content packaging)
one URL entry point and zero or more references to files that are required before the content is launched
NOTE The files described by a resource can be local or remote.
3.15
unit of content
either a file or a grouping of files which can be represented within a manifest
© ISO/IEC 2012 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC TR 12785-3:2012(E)
4 Abbreviated terms
CPIM Content Packaging Information Model
ITLET Information Technology for Learning, Education and Training
LET Learning, Education, and Training
LMS Learning Management System
LOM Learning Object Metadata
METS Metadata Encoding and Transport Schema
PIF Package Interchange File
SCO Sharable Content Object
SCORM Sharable Content Object Reference Model
URI Uniform Resource Identifier (IETF RFC 3986)
XML Extensible Markup Language (W3C XML)
XSD XML Schema Definition
5 Using content packages — Use cases and practices
The use cases in this clause illustrate key functionalities of ISO/IEC 12785 by focusing on particular goals that
users of the standard may have and then outlining how such goals can be achieved. The section is not
exhaustive neither in illustrating all features of the standard nor in outlining all uses of a specific feature.
5.1 Typical practice
Typically, a package contains all its resources in the PIF and uses a ZIP archive for its interchange format. It
has only one manifest; no child-manifests are included. All content files are declared in the manifest and are
included physically in the package. When material needs to be presented in more than one language or
accessibility modality, two types of organization are contained in the manifest.
Content packages that comply with the most popular content-packaging profile, ISO/IEC 29163 SCORM, also
typically follow this simple pattern.
Simple content packages are likely to be most widely supported in various Learning Management System
(LMS), and therefore, are the most robust in interoperability.
4 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC TR 12785-3:2012(E)
Table 1 — Use case of the classic package
Level: Primary use case
)
2
Actors:
Primary: Content authors
Secondary: Content repositories
Stakeholders: Content developers
Interest: Content-development tool developers
Basic flow of events:
• The content author creates required content.
• A PIF (usually a ZIP file) is created that includes a manifest file and Web
)
3
content resources simply using a packaging tool such as RELOAD .
• The PIF is deposited into a repository and/or LMS.
Alternative flow of
• A content author creates ISO/IEC 29163 SCORM compliant content.
events:
• A PIF is created including all ISO/IEC 29163 SCORM compliant files, such
as metadata.
• The PIF is deposited into a repository and/or LMS.
Success factors:
• All resources are contained within the PIF.
• Packages are easily ingested by (legacy) compliant LMS systems.

Note: The “Simple_Manifest_Core” package in the set of examples that is included with this standard is a typical instance
of a simple package. The example packages are available on the IMS
website: http://www.imsglobal.org/content/packaging/index.html
5.2 Keeping control over resources after a package has been published
Originally, a PIF, such as a ZIP archive, was intended to function solely as a means of transporting a course
from one delivery environment (e.g., an LMS) to another. In practice, however, often a course is delivered
from the PIF after the PIF has been imported in an LMS, thereby changing the nature and use of the PIF that
contains the course from a transport mechanism to a content management device.
Though this does work, there are cases where it is desirable not to copy the content that is aggregated in a
PIF, but have it reside on a central server. That way, access to the resources can be controlled more easily;
content files can be updated at any point in time and use monitored more accurately by the publisher.

2) Content authors design the logical structure of content,e.g. teacher, professor, and instructional designer.
3) See the reference: http://www.reload.ac.uk/tools.html.
© ISO/IEC 2012 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC TR 12785-3:2012(E)
Table 2 — Use case of keeping control over resources
Level: Primary use case
Actors: Primary: Content authors
Secondary: Content repositories and learners
Stakeholders: Content managers
Interest: Content authoring tool developers
Basic flow of events: 1) The content author searches for content files on a variety of repositories.
2) The content author composes a content package manifest that contains
absolute references to the remote files in the repositories.
3) The content package manifest is sent to a variety of LMSs.
4) A learner accesses the content package manifest in an LMS.
5) Content files are retrieved from the remote repositories independent from
LMS.
Alternative flow of 1) The content author creates new content files and deposits them in one or
events: more repositories.
2) The content author composes a content package manifest that contains
absolute references to the resources located remotely in the repositories.
3) References in the content package manifest are coded to uniquely identify
the instances of the manifest that are sent to a specific LMS or organization.
4) An LMS can be granted or denied access to the resources by the
repositories, depending on the construction of the references or some other
authentication and authorization mechanism determined by the repository.
Success factors:
• The content owner can control access to content files at any point in time.
• The content owner can monitor content file usage at any point in time.
• Updates to content files are propagated automatically.

5.3 Aggregate content at an appropriate level of granularity
A sharable content object (SCO) of ISO/IEC 29163 SCORM is the lowest aggregation level at which a
learner’s progress through a course can be tracked in ISO/IEC 29163 SCORM. Despite this fact, SCOs often
contain multiple pages of content. This makes it difficult to track precisely where a learner is in the material.
Child-manifests can be used to resolve this issue. Individual child-manifests can describe individual sub-
components (e.g. one manifest for each individual page of content) that would otherwise be undifferentiated in
a single SCO. As defined above (3.1) a child-manifest is a complete, subordinate manifest contained within or
(from ISO/IEC 12785 onwards) referenced by a main or parent manifest. A child-manifest describes a
complete logical package that is part of the larger logical package defined by its parent manifest.
6 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC TR 12785-3:2012(E)
Table 3 — Use case of aggregation content
Level: Primary use case
Actors: Primary: Content authors
Secondary: Content repositories
Stakeholders: Stakeholder: Content developers
Interest: Content development tool developers
Preconditions:
• All basic content files have already been authored.
• A hierarchy of content packages has been created; the package and
manifest on the highest level in this hierarchy references child manifests that
correspond to more specific contents on a lower level.
• The content development tool supports child-manifests, either contained
within or referenced by the parent manifests.
Basic flow of events: 1) Using a content development tool, a content author gathers basic content
into what will be independently reusable content packages.
2) The content author turns each of these into a content package which consist
of single-page SCOs.
3) The content author aggregates the packages into a single logical package in
one PIF.
Postconditions:
• The PIF contains one manifest document that contains the child-manifests
of the aggregated packages (see examples, below).
• Alternatively, the PIF contains a parent manifest that references child-
manifests that may be located in subdirectories defined in the content
package (see examples, below).
Success factors:
• The learner’s progress can be tracked at an appropriate level of granularity.
• Content assets can be authored and managed at a aggregation level that
makes reuse as easy as possible.

Child-manifest examples:
As an example of the use of child-manifests, suppose a content author was developing a lesson on camping
based on three existing content packages: “How to construct a tent”, “How to start a fire”, and “How to make
campfire snacks”. The content author can either (a) include the manifests for these existing content packages
in a parent manifest, or (b) reference child-manifests from the parent manifest. Referenced child-manifests
may be local to the interchange package or may be hosted remotely (for example in a repository).
© ISO/IEC 2012 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/IEC TR 12785-3:2012(E)

Figure 1 — An example of the use of child-manifests
5.4 Specialized packages with combination of various specifications
This section discusses packages which contain XML data as local content. These packages are considered
specialized because this configuration is often used in conjunction with other IMS specifications including:
• IMS ePortfolio
• IMS Learning Design
• IMS Learner Information Package
• IMS Question & Test Interoperability
• IMS Simple Sequencing
Guidance on how each of these specifications uses content packaging is provided in the relevant IMS
)
4
documentation set .

4) IMS specifications can be found in: http://www.imsglobal.org/specifications.html
8 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/IEC TR 12785-3:2012(E)
5.5 Working with child-manifests and applying IMS simple sequencing rules using the new
IPointer mechanism
Some specifications, such as IMS Simple Sequencing, add their own XML attributes to Item structure of
ISO/IEC 12785. Thought needs to be given as to how the information conveyed by those attributes affect the
tree-like structures that can be built with Item objects in an Organization objects. Specifically, conflicts may
exist among several sets of sequencing rules when a parent Manifest declares an association with one or
more child Manifest objects and all contain sequencing instructions. This is conceptually no different from
cases where sequencing rules exist on a parent Item that contains at least one child Item that also has
sequencing rules. When using IPointer objects, a key point to bear in mind is whether an Item becomes a
parent to a target Item in the external Manifest to which the IPointer points. This same logic applies to
Manifest objects that contain internal references to child Manifest objects.
Table 4 — Use case of child-manifests and sequencing rules
Level: Primary use case
Actors: Primary: Content authors and instructional designers
Secondary: Content tool developers
Stakeholders: Content developers
Preconditions:
• A requirement exists to construct a new content package with remediation
(i.e. an exercise for students requiring extra practice).
• The remediation should only be presented to the learner if the learner fails a
quiz. Conceptually, the new design may look like Figure 2, where A
represents the new content package, AA contains the quiz and X is the
content package to be used for remediation, if the learner does not satisfy
AA.
Display X only if AA
A
was not satisfied.
AA L1 X
AAA AAB XX XY

Figure 2 — Conceptual design of a new package
• The remote package (i.e., X, in Figure 2) cannot be altered by the content
package author.
• Conceptually, if a package reader were to process the structure in Figure 2,
the resulting structure should look like that in Figure 3.
A
AA X
AAA AAB XX XY

Figure 3 — Conceptual design of processed structure
© ISO/IEC 2012 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO/IEC TR 12785-3:2012(E)
Basic flow of events: 1) An instructional designer searches a repository and finds a content package
that has suitable remediation. The instructional designer needs to apply a
sequencing rule to X that says it should be displayed only if AA was not
satisfied.
2) However, L1 is a linking object that will be completely replaced and cannot
have associated sequencing rules to node A. Instead, the instructional
designer adds a new Item that will be the parent of the external structure.
3) The instructional designer applies sequencing rule for X to the new parent
(AB). Conceptually, the new content package would look like that in
Figure 4. In order to make the situation shown in Figure 4 work, the
instructional designer needs to introduce global variables. For AB to know if
AA was satisfied, the satisfaction status of AA would need to be mapped to
such a global variable, which can be read by AB.
Display X only if AA
A
was not satisfied.
AB
AA
AAA AAB L1 X
XX XY


Figure 4 — Conceptual design of the applied sequencing rule
Success factors:
• References to external manifests are processed and displayed as the
instructional designer originally intended, depending on learner responses.
• Sequenced content is easily reused for a variety of instructional purposes.

5.6 Packaging METS and other complex object encodings
Several formats exist for aggregating complex digital objects in addition to ISO/IEC 12785. In the library
community, for example, Metadata Encoding and Transport Schema (METS) is widely used, while ISO/IEC
21000-2 is used in many multimedia applications.
Ideally, complex digital objects should be transformable from one such format to another. However, this is not
always possible or even desirable. Sometimes, it may be preferable to exchange a complex digital object in
one format wrapped inside another. This approach can be used to exchange a complex digital object without
affecting its native format, structural integrity, or semantic fidelity.
10 © ISO/IEC 2012 – All rights reserved

---------------------- Page: 15 ----------------------
ISO/IEC TR 12785-3:2012(E)
Table 5 —
...