JULY 22,2004


ADVANCED DISTRIBUTED LEARNING

©2004Advanced Distributed Leaming. AllRightsReserved.


This page intentionally left blank.


2004 Advanced Distributed Learning. All Rights Reserved.


Advanced Distributed Learning (ADL)


Sharable Content Object Reference Model (SCORM®)


Content Aggregation Model (CAM) Version 1.3.1


Available at ADLNet.org

(http://www.adlnet.org/)


For questions and comments visit the ADL Help & Info Center at ADLNet.org


This page intentionally left blank.


Chief Technical Architect Philip Dodds


Technical Editor Schawn E. Thropp


Key ADL Technical Team Contributors to the SCORM Content Aggregation Model Version 1.3.1:


William Capone

Mary Krauland

Clark Christensen

Jeff Krinock

Jeffrey M. Falls

Lori Morealli

Dexter Fletcher

Angelo Panar

Matthew Handwork

Douglas Peterson

Rob Harrity

Jonathan Poltrack

Sue Herald

Betsy Spigarelli

Alan Hoberney

Schawn E. Thropp

Paul Jesukiewicz

Bryce Walat

Kirk Johnson

Jerry West


Key ADL Community Contributors to the SCORM Content Aggregation Model Version 1.3.1:


Mike Bednar

Claude Ostyn

Bill Blackmon

Nina Pasini

Howard Fear

Dan Rehak

Lenny Greenberg

Tyde Richards

Peter Hope

Roger St. Pierre

Boyd Nielsen

Brendon Towle


Acknowledgements

ADL would like to thank the following organizations and their members for their continued commitment to building interoperable e-learning standards and specifications:

Alliance of Remote Instructional Authoring & Distribution Networks for Europe (ARIADNE) (http://www.ariadne-eu.org/) Erik Duval

Eddy Forte Florence Haenny Ken Warkentyne

Aviation Industry CBT Committee (AICC) (http://www.aicc.org/)

Jack Hyde Bill McDonald

Anne Montgomery


Institute of Electrical and Electronics Engineers (IEEE) Learning Technology Standards Committee (LTSC) (http://ltsc.ieee.org/)

Erik Duval Mike Fore

Wayne Hodgins Tyde Richards Robby Robson

IMS Global Learning Consortium, Inc. (http://www.imsglobal.org/)

Thor Anderson Steve Griffin Mark Norton Ed Walker


(At Large)

Bob Alcorn

Chantal Paquin

Tom Grobicki

Mike Pettit

Tom King

Tom Rhodes

Chris Moffatt

Kenny Young


…and many others.


ADL would also like to thank the ADL Community for their commitment and contribution to the evolution of SCORM.


COPYRIGHT


Copyright 2004 Advanced Distributed Learning (ADL). All rights reserved.


DISTRIBUTION


Permission to distribute this document is granted under the following conditions:

  1. The use of this document, its images and examples is for non-commercial, educational or informational purposes only.

  2. The document, its images and examples are intact, complete and unmodified. The complete cover page, as well as the COPYRIGHT, DISTRIBUTION and REPRODUCTION sections are consequently included.


    REPRODUCTION


    Permission to reproduce this document completely or in part is granted under the following conditions:

    1. The reproduction is for non-commercial, educational or informational purposes only.

    2. Appropriate citation of the source document is used as follows:

    Source: Advanced Distributed Learning (ADL), Sharable Content Object Reference Model (SCORM®) Content Aggregation Model Version 1.3.1, 2004.


    For additional information or questions regarding copyright, distribution and reproduction, contact:

    ADL Co-Laboratory

    1901 North Beauregard Street, Suite 106

    Alexandria, VA 22311 USA

    (703) 575-2000


    This page intentionally left blank.


    Table of Contents

    SECTION 1 SCORM CONTENT AGGREGATION MODEL (CAM) OVERVIEW 1-1

      1. Introduction to the SCORM Content Aggregation Model (CAM) Book 1-3

        1. What is Covered in the SCORM Content Aggregation Model (CAM) Book? 1-3

        2. Using the SCORM CAM Book 1-4

        3. Relationship with Other SCORM Books 1-5

      2. The SCORM Content Aggregation Model 1-8

    SECTION 2 THE SCORM CONTENT MODEL 2-1

    1. SCORM Content Model Components 2-3

      1. Asset 2-3

      2. Sharable Content Object (SCO) 2-3

      3. Content Organization 2-5

      4. SCORM Meta-data Components 2-7

SECTION 3 SCORM CONTENT PACKAGING 3-1

    1. Content Packaging Overview 3-3

    2. Content Package Components 3-4

      1. Package 3-5

      2. Manifest 3-5

      3. Package Interchange File (PIF) 3-6

    3. Components of a Manifest 3-7

      1. Meta-data 3-7

      2. Organizations 3-7

      3. Resources. 3-15

      4. Physical Files 3-15

    4. Building Content Packages 3-16

      1. Manifest File 3-16

      2. (Sub)Manifests 3-43

      3. Content Package Manifest Extensions 3-48

      4. Content Package Manifest Href Handling 3-49

    5. SCORM Content Package Application Profiles 3-55

      1. Resource Package 3-55

      2. Content Aggregation Package 3-57

      3. SCORM Content Package Application Profile Requirements 3-59

    6. Best Practices and Practical Guidelines 3-61

      1. Multiple Organizations for a Single Course 3-61

      2. Packaging Learning Content for Reuse 3-61

      3. Using the <dependency> Element 3-62

SECTION 4 SCORM META-DATA 4-1

    1. SCORM Meta-Data Overview 4-3

    2. SCORM Meta-data Creation 4-5

      1. <lom> Element 4-8

      2. <general> Element 4-10

      3. <lifeCycle> Element 4-21

      4. <metaMetadata> Element 4-29

      5. <technical> Element 4-40

      6. <educational> Element 4-54

      7. <rights> Element 4-66

      8. <relation> Element 4-70

      9. <annotation> Element 4-78

      10. <classification> Element 4-82

      11. Common Data Types 4-91

    3. LOM XML Schema Validation Approaches 4-96

      1. Strict Schema Validation Approach 4-96

      2. Custom Schema Validation Approach 4-97

      3. Loose Schema Validation Approach 4-97

    4. Meta-data Extensions 4-98

      1. Data Element Extension 4-99

      2. Vocabulary Extension 4-100

    5. SCORM Meta-data Application Profiles 4-101

      1. Associating Meta-data with SCORM Components 4-102

      2. SCORM Meta-data Application Profile Requirements 4-108

SECTION 5 SCORM SEQUENCING AND PRESENTATION 5-1

    1. Sequencing and Presentation 5-3

      1. <sequencing> Element 5-3

      2. <controlMode> Element 5-5

      3. <sequencingRules> Element 5-7

      4. <limitConditions> Element. 5-16

      5. <auxiliaryResources> Element 5-18

      6. <rollupRules> Element 5-19

      7. <objectives> Element 5-26

      8. <randomizationControls> Element 5-34

      9. <deliveryControls> Element 5-36

      10. <constrainedChoiceConsiderations> Element 5-37

      11. <rollupConsiderations> Element 5-39

      12. <sequencingCollection> Element 5-41

    2. Presentation/Navigation Information 5-43

    3. Relationship to Content Packaging 5-46

APPENDIX A ACRONYM LISTING................................................................................................... A-1

ACRONYM LISTING ............................................................................................................................... A-3

APPENDIX B REFERENCES............................................................................................................... B-1

REFERENCES ........................................................................................................................................... B-3 APPENDIX C DOCUMENT REVISON HISTORY............................................................................. C-1

DOCUMENT REVISION HISTORY........................................................................................................ C-3


SECTION 1

SCORM Content Aggregation Model (CAM) Overview


This page intentionally left blank.


    1. Introduction to the SCORM Content Aggregation Model (CAM) Book

      The SCORM is often described as a set of books on a bookshelf. The Content Aggregation Model (CAM) book is one of a set of books (refer to Figure 1.1a: The Content Aggregation Model Book as Part of the SCORM Bookshelf). More information on the other SCORM books and their relationships to one another can be found in the SCORM 2004 Overview. The SCORM CAM book describes the components used in a learning experience, how to package those components for exchange from system to system, how to describe those components to enable search and discovery and how to define sequencing information for the components. The CAM promotes the consistent storage, labeling, packaging, exchange and discovery of learning content.

      Meta-data (from IEEE LOM 1484.12)


      Content Structure (derived from AICC)

      Sequencing Information (from IMS)

      Content Packaging (from IMS)

      Content Aggregation Model



      Key SCORM® Technologies

      • Sharable Content Object

      • Asset

      • Content Packaging

      • Meta-data

      • Sequencing Information


      Figure 1.1a: The SCORM Content Aggregation Model Book as Part of the SCORM Bookshelf


      1. What is Covered in the SCORM Content Aggregation Model (CAM) Book?

        There are several key concepts that are introduced in the SCORM Content Aggregation Model (CAM) book. The book describes responsibilities and requirements for building content and content organizations (e.g., course, lessons, modules, etc.). The book contains information on creating content packages, applying meta-data to the components in the content package and applying sequencing and navigation details in the context of a content package. SCORM Content Packaging, as described in this book, provides a consistent form for describing content structures, learning content, the meta-data that describes the various components of the content structures and sequencing and navigation

        rules. This consistency facilitates search and discovery of content packages and their resources (helping facilitate reuse of SCORM-conformant content), building of content organizations that will behave in a similar manner from system to system and standard understanding of the contents of the content package. General subjects discussed include:

        • Content Model: definition of common terminology used throughout the CAM book

        • Content Packaging: descriptions and requirements for aggregating and bundling learning content

        • Meta-data: descriptions and requirements for describing SCORM components

        • Sequencing and Navigation: descriptions and requirements for defining sequencing and navigation information


      2. Using the SCORM CAM Book

        This book will assist authoring tool vendors, content developers and anyone else wishing to create or edit:

        • SCORM Content Model Components (Assets, SCOs, Activities and Content Organizations),

        • SCORM Content Packages (with or without sequencing and navigation information) or

        • SCORM Meta-data

        This book will also assist those who develop systems that receive content packages. Various requirements are defined throughout the book that describe how to process content packages.

        Early portions of this book, Section 1: The SCORM Content Aggregation Model (CAM) Overview through Section 2: The SCORM Content Model, cover general CAM-related concepts. These sections are recommended reading for those seeking an introduction to the concepts behind the SCORM CAM and who may not wish to delve into its technical details. Others who may find these sections useful include those wishing to learn about updates to the SCORM CAM. Section 2.1.3: Content Organization, for instance, discusses how Activities impact the SCORM CAM.

        Section 3: SCORM Content Packaging is the first section of this book providing technical details specific to the CAM. It describes Manifests, Content Packages, SCORM Content Organization Package Application Profile, SCORM Resource Package Application Profile and Best Practices and Practical Guidelines. This section covers not only the technical details about the various individual components of SCORM Content Packages, but it also covers how to assemble content packages, showing snippets of manifests with explanations.

        Section 4: SCORM Meta-Data covers all aspects of creating meta-data for labeling purposes, to include Learning Object Metadata (LOM) Extensible Markup Language

        (XML) validation approaches, meta-data extensions and meta-data application profiles. The section also describes how to associate meta-data to SCORM Content Model Components in a content package.

        Section 5: SCORM Sequencing and Navigation covers ways in which the introduction of sequencing and navigation information affect the SCORM Content Aggregation Model. The section also outlines how to build sequencing and navigation information in XML and how to place those rules in a content package manifest. The section describes the requirements for building XML that represents the desired sequencing strategies.


      3. Relationship with Other SCORM Books

        While the various SCORM books are intended to stand alone, there are areas of overlap or mutual coverage. For instance, while this book focuses primarily on elements of SCORM content such as SCOs and Assets, those objects are launched by

        SCORM-conformant LMSs, and so the SCORM Run-Time Environment book [2], covering content launch is mentioned numerous times.

        Similarly, while the Sequencing and Navigation (SN) book covers the details of SCORM sequencing and navigation processes, including detailed coverage of how an LMS evaluates navigation requests and related activities, this book deals with manifests which contain the sequencing information described by the SN book, and so some of the basics of sequencing and navigation are touched on.

        To help clarify areas of overlap, Section 1.1.3.1: The SCORM Run-Time Environment Book and Section 1.1.3.2: The SCORM Sequencing and Navigation Book provide brief descriptions of the contents of these SCORM books.


        1. The SCORM Run-Time Environment Book

          The purpose of the SCORM RTE is to provide a means for interoperability between SCOs and LMSs. SCORM provides a means for learning content to be interoperable across multiple LMSs regardless of the tools used to create the content. For this to be possible, there must be a common way to launch content, a common way for content to communicate with an LMS and predefined data elements that are exchanged between an LMS and content during its execution. The three components of the SCORM RTE are defined in this document as Launch, Application Program Interface (API) and Data Model. The technical details of these elements are described in the SCORM RTE book, but a brief overview of each of these elements of the RTE follows.

          Launch includes defining the relationship between LMSs and SCORM content such that all SCORM-conformant content is dependant upon a SCORM-conformant LMS to be delivered and displayed to the learner. In addition, LMSs have the responsibility to determine which SCORM content is to be delivered next. These new responsibilities, described in the SCORM SN book, are also touched on in the SCORM RTE book.

          The SCORM API, as described in the SCORM RTE book, provides a set of predefined methods that are agreed upon by both LMS vendors and content authoring tool vendors to be made available for purposes of communication between an LMS and the SCOs it launches. These functions complete the launch process by providing a means to establish a “handshake” between the SCO and the LMS that launched it, and to break that handshake when the learning session with the SCO is terminated. In addition, they provide the means for SCORM content to “set” and “get” data on the LMS, such as assessment results, and to check for and warn the user about any errors that may occur during these processes.

          The SCORM Run-Time Environment Data Model, as described in the SCORM RTE book, provides the data elements that can be used to “get” and “set” data from and to an LMS. For instance, when passing a test score from a learner, a SCO would use the SCORM Run-Time Environment Data Model element known as cmi.score.scaled to inform the LMS how a user performed in the test. This and all other SCORM Data Model elements are described in detail in the SCORM RTE book.

          Various concepts described in the CAM have impacts on the SCORM RTE. Data defined in a content package manifest impact some initial values for some of the SCORM Run-Time Environment Data Model elements. Data from the manifest is used in the process of delivering and launching content to the learner and impacts the run-time environment. These and other relationships are described throughout the CAM.


        2. The SCORM Sequencing and Navigation Book

          The SCORM SN book is based on the IMS Simple Sequencing (SS) Specification Version 1.0, which defines a method for representing the intended behavior of an authored learning experience such that any conformant LMS will sequence discrete learning activities in a consistent way.

          The SCORM SN Model defines how IMS Simple Sequencing applies and is extended in a SCORM environment. It defines the required behaviors and functionality that SCORM-conformant LMSs must implement to process sequencing information at run- time. More specifically, it describes the branching and flow of learning activities in terms of an Activity Tree, based on the results of a learner’s interactions with launched content objects and an authored sequencing strategy. An Activity Tree is a conceptual structure of learning activities managed by the LMS for each learner.

          The SCORM SN book describes how learner-initiated and system-initiated navigation events can be triggered and processed, resulting in the identification of learning activities for delivery. Each learning activity identified for delivery will have an associated content object. The SCORM RTE model describes how identified content objects are launched. The sequence of launched content objects, for a given learner and content structure, provides a learning experience (learner interaction with content objects); the SCORM RTE model describes how the LMS manages the resulting learning experience and how that learning experience may affect the Activity Tree.

          Various concepts described in the CAM have relationships to the SCORM SN book. The CAM describes how to build sequencing information and represent that information in the XML. The CAM then describes how to build onto the existing manifest to apply the sequencing information. See the SCORM Sequencing and Navigation book for more details on the relationship between the XML binding of the sequencing information and the processes and behaviors of that information.


    2. The SCORM Content Aggregation Model

The SCORM Content Aggregation Model represents a learning taxonomy neutral means for designers and implementers of instruction to aggregate learning resources for the purpose of delivering a desired learning experience. A learning resource is any representation of information that is used in a learning experience. Learning experiences consist of activities that are supported by electronic or non-electronic learning resources.

One activity in the process of creating and delivering learning experiences involves the creation, discovery and gathering together, or aggregation, of simple assets into more complex learning resources and then organizing the resources into a predefined sequence of delivery. The SCORM Content Aggregation Model supports this process and is made up of the following:


SECTION 2

The SCORM Content Model


This page intentionally left blank.


    1. SCORM Content Model Components

      The SCORM Content Model describes the SCORM components used to build a learning experience from learning resources. The Content Model also defines how these lower- level sharable, learning resources are aggregated into higher-level units of instruction.

      The SCORM Content Model is made up of Assets, Sharable Content Objects (SCOs) and Content Organization.


      1. Asset

        The most basic form of a learning resource is an Asset. Assets are an electronic representation of media, such as text, images, sound, assessment objects or any other piece of data that can be rendered by a Web client and presented to a learner (refer to Figure 2.1.1a). More than one asset can be collected together to build other assets. In some cases, Assets may be launched as part of the learning experience.

        Asset JavaScript Functions

        Asset

        MP3

        Audio

        Asset

        HTML

        Fragment

        Asset

        XML

        Document


        Asset

        WAV Audio

        Asset

        JPEG

        Image

An Asset can be described with Asset Meta-data (see Asset Meta-data definition below) to allow for search and discovery within repositories, thereby enabling opportunities for reuse. The manner for associating Assets to Asset Meta-data is the Content Package (Refer to Section 3: SCORM Content Packaging).





Asset Web Page

Asset Flash Object

Asset

GIF

Image

Figure 2.1.1a: Examples of Assets


      1. Sharable Content Object (SCO)

        A SCO is a collection of one or more Assets that represent a single launchable learning resource that utilizes the SCORM RTE to communicate with an LMS. A SCO represents the lowest level of granularity of a learning resource that is tracked by an LMS using the SCORM Run-Time Environment Data Model. The only difference between a SCO and

        an Asset is that the SCO communicates with an LMS using the IEEE ECMAScript Application Programming Interface for Content to Runtime Services Communication draft standard [1]. Figure 2.1.2a below shows an example of a SCO composed of several Assets.

        To improve reusability, a SCO should be independent of its learning context. For example, a SCO could be reused in different learning experiences to fulfill different learning objectives. In addition, an Activity (see Content Organization) may aggregate more than one SCO resource (and/or Asset resource) to form a higher-level unit of instruction or training that fulfills higher level learning objectives.

        SCOs are intended to be subjectively small units, such that potential reuse across multiple learning contexts is feasible. SCORM does not impose any particular constraints on the exact size of a SCO. During content design and authoring activities, when determining the size of a SCO, thought should be given to the smallest logical size of content to be tracked by an LMS at run-time. Reuse requirements for an organization will impact decisions about the size of SCOs. Other factors that may impact the decisions about the size of SCOs include how much information is required to achieve a learning outcome and the point where a branching decision is required for sequencing.

        Sharable Content Object (SCO)

        Asset JavaScript Functions

        Asset

        HTML

        Fragment

        Asset

        WAV Audio

        Asset

        Flash Object

        Asset

        JPEG

        Image

SCOs must Initialize and Terminate communication with an LMS. The list below details the SCO provided functionality:

A SCO can be described with SCO Meta-data (see SCO Meta-data definition below) to allow for search and discovery within repositories, thereby enabling opportunities for reuse. The manner for associating SCOs to SCO Meta-data is the Content Package (Refer to Section 3: SCORM Content Packaging).



Figure 2.1.2a: Sharable Content Object

A SCO is required to adhere to the requirements defined in the SCORM Run-Time Environment [2]. This implies that it must have a means to locate an LMS provided API Instance and must invoke the minimum API methods ( Initialize(“”) and Terminate(“”) ). There is no obligation to invoke any of the other API methods as those are optional and depend upon the nature of the content.

The requirement that a SCO must utilize the SCORM RTE yields the following benefits:


      1. Content Organization

        A Content Organization is a map that represents the intended use of the content through structured units of instruction (Activities). The map shows how Activities relate to one another. Figure 2.1.3a below shows an example of a Content Organization.

        The Activities represented in a Content Organization may consist of other Activities (sub- Activities), which may themselves consist of other activities. There is no set limit to the number of levels of nesting for Activities. While learning taxonomies may be associated with hierarchical levels of Activities, (e.g., course, chapter, module, etc.), this is not a requirement. Activities that do not consist of other Activities (leaf activities) will have an associated learning resource (SCO resource or Asset resource) that is used to perform the activity.

        Content Organization

        Content Aggregation

        Organization

        Item

        Resource

        (Asset)

        Item

        Resource

        (Asset)

        Item

        Resource

        (SCO)

        Resource

        (Asset)

        Item

        Resource

        (Asset)

        Resource

        (Asset)

        Item

        Resource

        (SCO)

        Activities

        Resources

        Activities that consist of other Activities are also called Clusters in the SCORM SN book. Refer to the SCORM SN book for more details on how behaviors can be defined for Activities and Clusters.



        Figure 2.1.3a: Content Organization

        Content Organization Meta-data can describe Content Organizations, thereby enabling opportunities for reuse. The manner of associating a Content Organization to Content Organization Meta-data is the Content Package (Refer to Section 3: SCORM Content Packaging).

        Each Activity in a Content Organization can reference Activity Meta-data to allow for search and discovery within repositories, thereby enabling opportunities for reuse. The manner for associating Activities to Activity Meta-data is the Content Package (Refer to Section 3: SCORM Content Packaging).

        Sequencing only applies to Activities. The intended sequencing of Activities is defined as part of the Content Organization, by structuring Activities in relation to one another and by associating sequencing information with each Activity. The LMS is responsible for interpreting the sequencing information described in the Content Organization and applying sequencing behaviors (Refer to Section 5: SCORM Sequencing and Navigation of this document for details on Sequencing) to control the actual sequence of the learning resources at run-time.

        This development strategy represents a departure from the way courseware has been developed using stand-alone computer-based training (CBT) authoring tools. In the past, these tools typically embedded all of the sequencing and navigation information that governs what part of the course the student will view next in proprietary data formats. In nearly all cases, authoring tools or systems defined and implemented proprietary and sometimes unique sequencing methods for content. Before the arrival of SCORM and the shift toward an interoperable development strategy, it was extremely difficult to share content between different authoring environments and equally difficult to reuse content in other contexts that involved different sequencing requirements.

        Within SCORM, sequencing information is defined on the Activities represented in the Content Organization and is external to the learning resources associated with those Activities. It is the responsibility of the LMS to launch learning resources associated with the activities in response to applying the defined sequencing behaviors. This is conceptually important because learning resource reuse is limited if a learning resource has embedded sequencing information that is context-specific to the course. For example, if a learning resource contained a “hardwired” branching to another learning resource under specific conditions, it could not be used in a different course in which the second learning resource might not be applicable or available. The reusability of a learning resource depends on it being independent and self-contained.

        SCORM recognizes, however, that some learning resources may contain internal logic to accomplish a particular learning task. Such a learning resource might branch within itself depending on user interactions. These branches are all self-contained, relevant to a stand- alone learning resource and are not usually visible to the LMS. Importantly, internal branching must not reference external learning resources that may or may not be present in other content organizations. This is an important area that content developers should pay attention to when determining what learning resources should be used and how they are to be aggregated.

      2. SCORM Meta-data Components

        The SCORM Meta-data Profiles represents a mapping and recommended usage of the IEEE Learning Technology Standards Committee (LTSC) Learning Object Metadata (LOM) elements for each of the SCORM Content Model Components. In general, guidance is provided for meta-data to be applied to Assets, SCOs, Activities, Content Organizations and Content Aggregations to describe them in a consistent fashion such that they can be identified, categorized, searched for and discovered within and across systems to further facilitate sharing and reuse.

        Policies governing the application of meta-data to the components of the Content Aggregation Model should be defined within organizations that wish to enable reuse based on the requirements of those organizations. SCORM does not seek to impose requirements related to the scope of meta-data tagging of Content Model components, but rather seeks to provide practical, standards-based guidance for those organizations wishing to enable sharing and reuse.


        1. Content Aggregation Meta-data

          Content Aggregation Meta-data describes the content aggregation (i.e., the content package) as a whole. The purpose of applying Content Aggregation Meta-data is to enable discoverability of the Content Aggregation and to provide descriptive information about the Content Aggregation as a whole. The requirements for any meta-data built for a Content Aggregation shall match those requirements set forth in the Content Aggregation Meta-data Application Profile.


        2. Content Organization Meta-data

          Content Organization Meta-data describes the Content Organization. The purpose of applying Content Organization Meta-data is to enable discoverability within, for example, a content repository and to provide descriptive information about the content structure, as a whole, defined by the Content Organization. The requirements for any meta-data built for an Content Organization shall match those requirements set forth in the Content Organization Meta-data Application Profile.


        3. Activity Meta-data

          Activity Meta-data describes an individual Activity. The purpose of applying Activity Meta-data is to make the Activity accessible (enabling discovery) within a content repository. The meta-data should describe the Activity as a whole. The requirements for any meta-data built for an Activity shall match those requirements set forth in the Activity Meta-data Application Profile.


        4. SCO Meta-data

          Meta-data can be applied to SCOs to provide descriptive information about the content in the SCO independent of any usage or potential usage within courseware content. This

          meta-data is used to facilitate reuse and discoverability of such content within, for example, a content repository. The requirements for any meta-data built for a SCO shall match those requirements set forth in the SCO Meta-data Application Profile.


        5. Asset Meta-data

          Meta-data can be applied to Assets to provide descriptive information about the Assets independent of any usage or potential usage within courseware content. This meta-data is used to facilitate reuse and discoverability, within, for example, a content repository during content creation. The requirements for any meta-data built for an Asset shall match those requirements set forth in the Asset Meta-data Application Profile.


        6. Application of Meta-data

          The mechanism for binding the Content Model components that were discussed earlier to the matching Meta-data application profile is the Content Package as described in SCORM. There are currently five places meta-data can be applied within a content package:

          • Manifest: Meta-data at the manifest level describes the content package as a whole. Meta-data placed at the manifest level is SCORM Content Aggregation Meta-data.

          • Organization: Meta-data at the organization level describes the Content Organization as a whole. This may be a course, unit, lesson or any other organized instructional unit. Meta-data placed at the organization level is SCORM Content Organization Meta-data.

          • Item: Meta-data at the item level describes a nested hierarchy of Activities in a context sensitive manner. When associated with an item, the SCORM Activity Meta-data definition must be used.

          • Resource: Meta-data at the resource level describes a SCO resource or an Asset resource in a context insensitive manner. This meta-data is bound by either the SCORM SCO Meta-data or Asset Meta-data definitions (Determined by the type of resource - adlcp:scormType attribute).

          • File: Meta-data at the file level describes an Asset in a context insensitive manner. This meta-data is bound by the SCORM Asset Meta-data definition.


SECTION 3

SCORM Content Packaging


This page intentionally left blank.


3.1. Content Packaging Overview

Once learning content is designed and built, there is a need to make the content available to learners, authoring tools, repositories or Learning Management Systems (LMSs). The IMS Content Packaging Specification was designed to provide a standard way to structure and exchange learning content.

The purpose of the Content Package is to provide a standardized way to exchange learning content between different systems or tools. The Content Package also provides a place for describing the structure (or organization) and the intended behavior of a collection of learning content.

Content packages are expected to be used to move learning content or collections of learning content between LMSs, development tools and content repositories. The IMS Content Packaging Specification [3] provides a common “input/output” format that any system can support.

SCORM Content Packaging is a set of specific requirements and guidance, or application profiles, of the IMS Content Packaging Specification. SCORM Content Packages adheres strictly to the IMS Content Packaging Specification and provides additional explicit requirements and implementation guidance for packaging Assets, SCO and Content Organization.

This section is organized as follows:

Section 3.2: Content Package Components defines the key concepts that deal with a content package. These key concepts are useful for getting a base understanding of a content package before describing the specific requirements.

Section 3.3: Components of a Manifest defines the makeup of a Content Package manifest. The manifest acts as the “packaging slip” for the content package. It describes the components of the content package.

Section 3.4: Building Content Packages defines the process of building a content package. The section focuses on the creation of the content package and the manifest file. The section describes the XML components of the manifest and the requirements for using those XML components.

Section 3.5: SCORM Content Package Application Profiles defines specifically how to create SCORM-conformant packages that contain Assets, SCOs and Content Organizations. This section describes the two types of application profiles and the requirements associated with those profiles.

Section 3.6: Best Practices and Practical Guidelines defines a collection of best practices and guidelines when building or processing content packages.


    1. Content Package Components

      This section contains an overview of content packages, the nomenclature used to describe content packages and the makeup of content packages. The IMS Content Packaging Specification describes data structures that are used to provide interoperability of

      Internet-based content with authoring tools, LMSs and run-time environments. The objective of the IMS Content Packaging Specification is to define a standardized set of structures that can be used to exchange content. The scope of the IMS Content Packaging Specification is focused on defining interoperability between systems that wish to import, export, aggregate and disaggregate content packages.

      A Content Package contains two major components:

      • A special XML document describing the content structure and associated resources of the package called the manifest file (imsmanifest.xml). Refer to Section 3.3: Components of a Manifest for more details on manifests. A manifest is required to be present at the root of the content package.

      • The physical files making up the content package.

      Figure 3.2a is a conceptual diagram that illustrates the components of a Content Package.


      Meta-data

      Organizations

      Resources

      (sub)Manifest(s)

      Content Package


      Manifest File (imsmanifest.xml)

      Manifest


      Physical Files

      (The actual Content, Media, Assessment, and other file)


Figure 3.2a: Content Package Conceptual Diagram

      1. Package

        A package represents a unit of learning. The unit of learning may be part of a course that has instructional relevance outside of a course organization and can be delivered independently, as a portion of a course, an entire course or as a collection of courses.

        Once a package arrives at its destination, the package must allow itself to be disaggregated or aggregated. A package must be able to stand alone; that is, it must contain all the information needed to use the packaged contents for learning when it has been unpacked.


      2. Manifest

        A manifest is an XML document that contains a structured inventory of the content of a package. If the content package is intended for delivery to an end user, the manifest also contains information about how the content is organized.

        The scope of a manifest is elastic. A manifest can describe part of a course that can stand by itself outside of the context of a course (an “instructional object”), an entire course, a collection of courses, or just a collection of content that is to be shipped from one system to another. When packaging a collection of courses, such a content package would typically have to be disaggregated in order to be delivered to learners in a practical LMS run-time system. How to do this disaggregation is out of scope with this version of SCORM. At this point there is no consensus or standard on how to publish a very large or very complex package in a practical LMS, because of different LMS systems and repositories use different methods to represent or store the learning content to deliver to learners.

        The general rule is that a package always contains a single top-level manifest that may contain one or more (sub)manifests. The top-level manifest always describes the package. Any nested (sub)manifests describe the content at the level at which the (sub)manifest is scoped, such as “course”, “instructional object” or other.

        The manifest shall adhere to the following requirements (as defined by the IMS Content Packaging Specification)

        • The manifest file shall be named imsmanifest.xml

        • The imsmanifest.xml and any of its supporting control files (e.g., DTD, XSD) shall be at the root of the content package. If extensions are used to describe organizational defined features and those features are represented in XML, then any and all control files also are required to be at the root of the package. This includes any and all control files needed to validate XML instances including those referenced by the <adlcp:location> element.

        • All requirements defined in the IMS Content Packaging XML Binding Specification, any restrictions and additional requirements to the IMS binding as defined in Section 3.4: Building Content Packages.

      3. Package Interchange File (PIF)

        The Package Interchange File (PIF) is a binding of the content package components in the form of a compressed archive file. The PIF contains the imsmanifest.xml, all control files and the resources referenced in the content package (those that are local to the PIF, i.e., contained in the content package). SCORM recommends that content packages be created as PIFs. The PIF provides a concise Web delivery format that can be used to transport content packages between systems. If a PIF is used for representing the content package, SCORM requires that the PIF be conformant with RFC 1951 [12]. In addition to this requirement, SCORM mandates that the archive format be PKZip v2.04g (.zip). This .zip file is conformant to RFC1951.


    1. Components of a Manifest

      Manifest

      The manifest file represents the information needed to describe the contents of the package. Figure 3.3a describes the makeup of a manifest file.


      Meta-data

      Organizations

      Resources

      (sub)Manifest(s)


      Figure 3.3a: Components of a Manifest

      The manifest is composed of four major sections:

      • Meta-data: data describing the content package as a whole

      • Organizations: contains the content structure or organization of the learning resources making up a stand-alone unit or units of instruction.

      • Resources: defines the learning resources bundled in the content package

      • (sub)Manifest(s): describes any logically nested units of instruction (which can be treated as stand-alone units)


      1. Meta-data

        Meta-data is defined as data about data. The meta-data depicted in Figure 3.3a is used to describe the content package (i.e., Content Aggregation) as a whole. This meta-data enables the search and discoverability of the content package itself. It also enables a mechanism for describing the characteristics of the content package.

        ADL Note: Meta-data can also be used at various locations within the manifest to describe the different aspects of the content package (Refer to Section 4.5.1: Associating Meta-data with SCORM Components for more information).


      2. Organizations

        The Organizations component is used to describe how the content is organized in the content package. It may contain one or more Organization components, each of which describes a particular structure for the content of the package. The current version of the IMS Content Packaging Specification only defines one form of content organization,

        which is in the shape of a tree or hierarchy. Neither the IMS Content Packaging Specification, nor SCORM, specifies whether this hierarchy should represent a particular learning taxonomy or nomenclature. In other words, SCORM does not specify terms such as “module”, “lesson” and so on to describe the levels of hierarchy in a content organization. Such terms tend to be resolved in a particular way. Therefore, the choice of nomenclature is left to the content developer.


        1. Multiple Content Organizations

          The IMS Content Packaging Specification separates learning resources from the way those resources are organized, allowing for one or more uses of the same learning resources within different contexts or uses.

          In order to deliver the content package to a learner in an LMS, there must be at least one content organization. In some cases, it is useful to define different ways to use the content in a package. Each of these ways is represented in a different content organization. Even if there are several content organizations, there is always a designated organization to use by default when the entity that uses the package cannot decide which of the content organizations to use.


        2. Content Organization

          The content organization describes how the content of the content package is organized for use. In SCORM 1.2, the only defined use for a content organization was as a kind of table of contents for the resources in the content package. In this version of SCORM, the content organization is also used as a way to describe a hierarchy of learning activities that exploit the learning resources. These resources are described in another part of the manifest.

          The content organization should not be confused with the physical structure of the content package, or with the structure of the manifest itself. For example, the files in a content package are often organized in a hierarchy of folders, but that structure in itself cannot tell the user of a content package how to use the content of the package.

          The purpose of the content organization is to provide the content developer with the means to specify cohesive units of instruction that use collections of learning resources. Such a unit of instruction is a hierarchy of learning activities, for which specific behaviors and rules may be prescribed in such a way that this activity structure and the associated behaviors can be reproduced in any SCORM-conformant LMS environment.

          For any activity defined in a content organization, the content developer may or may not define specific behaviors and rules. In the absence of specific rules, the content organization is just a map that can be used to navigate at will through the learning resources defined in the content package. By adding specific rules and behaviors, the content organization becomes a guide that prescribes how an LMS must manage the learner’s experience and use of the learning resources.

          A content organization can be seen as a structured map of learning resources, or a structured activity map to guide the learner through a hierarchy of learning activities that use the learning resources. One content developer may choose to structure the content organization as a table of contents for the learning resources, while another content developer may choose to structure the content organization as an adaptive guided path through a learning experience, invoking learning resources only if and when they are needed. A third content developer may create a content organization where some discovery activities include a free form use of some of the learning resources, while other activities are more formally managed.

          An LMS may create its own internal representation for a content package and its contents. The specification of a content organization in SCORM does not imply that LMS systems are required to adopt the content organization model or to store the package components using the same structural organization.

          The Organizations component defined in the IMS Content Packaging Specification provides the framework for the information that is required to represent the content structure. By design, the Organization component also contains the ability to add, for every item in the organization, additional information such as meta-data or behavior rules and prescriptions. SCORM refers to such an Organizations component, and to what it can represent as the “Content Organization.”

          The Content Organization is not an inventory of the actual learning resources, and it does not describe those resources. The IMS Content Packaging model also provides a clean way to inventory and bundle all of the physical files required to deliver the learning resources, as well as to identify relationships between files that belong to one or more learning resources, including externally referenced resources that are not contained as physical files within a package.

          1. Authoring Content and Content Collections

            Content organizations provide the means to represent the structure of collections of learning resources. This is a relatively new approach to designing learning content. In the past, CBT authoring tools provided the means to create parts of a course as well as how and when those parts were to be presented to the learner. The learning resources and the content organization were usually inseparable, and developed using the same tools and proprietary data formats. The shift to Internet-based technologies and the notion of building reusable content objects changed the authoring process considerably.

            Within SCORM, it is the LMS that is responsible for delivering the content according to the prescriptions embodied in the content organization. That means that the LMS must know how and when a designer intended the learning resources included in a content package to be presented to the learner. The content organization, which is located in the organizations section of the package manifest, allows the designer to provide the LMS with this information. This means that authoring a unit of instruction consists of authoring or collecting learning resources, and also authoring a content organization that uses those learning resources – perhaps using completely different authoring tools.

            In SCORM, there are two distinct products of authoring: Authored content organization information, which is used as a prescription by the LMS and processed during run-time, and authored learning resources, which are launched in a browser environment as prescribed by the content organization. Unlike many older CBT models, here the structure is separate from the content. The structure is now fully exposed and can be represented in a standardized form. Content packages can now be delivered in a predictable way, to produce comparable learning experiences in different LMS environments.


        3. Representing Content Structure

          A SCORM content organization includes components that are intended to define different aspects of a content structure:

          • Content Hierarchy: This is a tree-shaped representation, much like a table of contents that represents a logical organization for the learning resources or activities that use the learning resources. In many cases, but not all, this hierarchical tree can be traversed in a specific order that represents the default order in which an author intends for the learner to progress through the material.

          • Meta-data: This is optional, context-specific descriptive data about an activity defined in the content organization. Such meta-data can be used to describe how a particular learning resource is to be used in a particular content organization (e.g., competency or objectives that may be met by a learner when the learning resource is used in a particular activity).

          • Sequencing, Adaptive Sequencing and Navigation: Optional prescriptions may be embedded in the content organization if the content developer wants to control which learning resources is to be presented to the learner as the learner navigates through the content. By default, if no sequencing and navigation prescription is defined, a learner may choose any content item at will. Adding specific prescriptions can alter this default behavior. For example, adding a flow prescription to the items in the content organization will direct the LMS to guide the navigation in the order defined by the organization tree. More complex adaptive sequencing can be based on the completion status of certain learning resources or on more complex computation of user preferences or assessment results.

          Content Organizations are intended to represent a wide variety of approaches to the aggregation of content. A content organization can represent a content aggregation ranging from very, very small learning resources – as simple as a few lines of Hypertext Markup Language (HTML) or a short media clip – to highly interactive learning resources that are tracked by an LMS. The SCORM Content Aggregation Model is neutral about the complexity of content, the number of hierarchical levels of a particular unit of instruction (i.e., taxonomy) and the instructional methodology employed.

          Table 3.3.2.2a depicts examples of several possible curricular taxonomy models as used by American and Canadian Armed Forces, which can be represented in a SCORM content organization.


          Table 3.3.2.2a: Example of Curricular Taxonomy Models


          US Army

          US Air Force

          US Marine Corps

          Canadian Armed Forces

          Course

          Course

          Course

          Course

          Module

          Block

          Phase

          Performance Objective

          Lesson

          Module

          SubCourse (Annex)

          Enabling Objective

          Learning Objective

          Lesson

          Lesson

          Teaching Point

          Learning Step

          Learning Objective

          Task




          Learning Objective




          Learning Step



          1. Content Hierarchy

            A collection of learning resources can usually be organized into a hierarchy, which can be represented as a content organization. Another approach to organizing learning resources is to define a hierarchy of activities that rely on the resources to provide a specific learning experience. In this case the top-level of the hierarchy is the main activity, which can consist of sub-activities, which can themselves consist of sub- activities. Depending on the design methodology, this hierarchical grouping might be used to represent concepts like Course, Chapter, Topic or similar terms that represent how the content is organized for delivery to a learner.

            The IMS Content Packaging Specification defines a set of terms that are used in representing the content hierarchy. Figure 3.3.2.2.1a depicts how a content organization forms a hierarchical structure that maps to a collection of learning resources (as defined by the IMS Content Packaging Specification). The hierarchical structure is a tree of nested Item elements. The root of the tree is the Organization element. An Item element may reference a Resource element, which describes a specific learning resource to be launched when the Item is used as an activity. The same Resource element may be referenced by more than one Item element.

            SCORM and the IMS Simple Sequencing Specification [5] are application profiles of the IMS Content Packaging Specification, and as such they add a couple of restrictions. One is that only leaf Items (Items that do not have children) may reference a learning resource. Another is that an Organization must contain at least one Item.

            In addition, SCORM requires that a learning resource be of one of two types. Either a SCO or an Asset. These will be described in more details in the section on Resources.



            organization

            item

            item

            resource

            Asset

            item

            resource

            SCO

            item

            item

            SCO

            item

            resource

            item

            resource

            Asset

            Figure 3.3.2.3.1a: IMS Content Hierarchy Terminology


          2. Meta-data

            When a learning resource is created with the intent to make it reusable, it is a best practice to describe the learning resource with meta-data. Meta-data allow the learning resource to be found when it is stored in a content package or in a repository. It also makes the learning resource more reusable since one can, by inspecting only the meta- data, decide to reuse it without having to actually open and inspect the resource itself. Such meta-data is considered context-independent, since it describes the learning resource regardless of where it can be found, independently of any particular use in the context of a specific learning strategy. For example, imagine a simple SCO that teaches how to thread a needle. Meta-data describing the SCO might describe the skill to be acquired – inserting a thread through the eye of a needle – and might further describe that a simulation is part of the learning experience. This meta-data does not, however, describe how the needle might be used. When the use of a learning resource is defined as part of a learning strategy, additional meta-data may be used to describe the activity that uses the resource.

            Meta-data that is specific to a particular learning strategy is called context-specific meta- data and is incorporated in the content organization. For example, the meta-data may include an explanation of why that particular activity is inserted at that particular place in an instructional sequence.

            Context-independent meta-data usually refers to immutable meta-data that describes digital assets, content objects or collections of objects. Context-dependent meta-data, on

            the other hand, usually refers to meta-data that makes sense only in the context of a particular content organization.

            Developing and applying meta-data to learning resources and collections of learning resources is a new concept to many. Best practices for doing this have yet to be developed. In some cases, the principal purpose for meta-data is discovery and reuse of content. In other cases, it is strictly informational and provides authors with information about the design and intent of the described learning object or item in a content organization. Some have theorized that meta-data could be provided to learners to help them navigate through content. No consensus on common usage of meta-data has so far emerged, but provisions have been made in these specifications for a variety of potentially valuable uses of meta-data.

            If a content package is intended only for delivery to learners, and there is no intent to ever reorganize it or disaggregate it to reuse its components in another organization, adding detailed meta-data for each element in the content package may be counter-productive, since such meta-data only makes the content package and its manifest more expensive to store, transmit and manage. On the other hand, if there is any chance that the content package may have to be modified, reorganized or disaggregated for reuse at some time in the future, then it makes sense to provide meta-data for every element that might be reused or need to be interpreted. In case of doubt, past experience with content seems to indicate that it is probably best to add meta-data, even though they may be stripped when a streamline delivery package is required.

          3. Sequencing, Adaptive Sequencing and Navigation

            Sequencing and Navigation refers to the behaviors that an LMS must follow in order to present a specific learning experience as intended by an author or content developer.

            This learning experience may be free play, in which the learner can choose any item in the content organization in any order, or it may be guided by a flow through the structure of the content organization. The learning experience can be adaptive, with different behaviors that depend on the learner’s performance or other variables that can be tracked by the LMS.

            SCORM defines a default set of sequencing information that governs sequencing and navigation for a specific content organization. However, the default sequencing information only provides for free play. Many content developers and instructional designers prefer to use specific learning or instructional strategies. In those cases, the content developer can define specific sequencing information that prescribes how an LMS will manage the learning experience.

            The sequencing information is associated with the elements in the content organization tree and each of these elements represents an activity that the learner may engage in under control of the sequencing information. Application of sequencing information typically results in either the launching of a learning resource, or a choice the learner must make within the constrains defined by the content developer. Because the sequencing and navigation information is part of the content organization, which is itself part of the package manifest, the intended behaviors can be embedded in a content

            package in such a form that the package can be used to deliver the same learning experience on any SCORM-conformant LMS.

            SCORM Sequencing and Navigation provides, among other things, the ability to define highly adaptive activity sequencing. For example, it allows for conditional branching to another activity depending on whether the learner has completed some task, attained an acceptable score or achieved a certain objective. Sequencing and Navigation information embedded in a content organization can prescribe whether and how an LMS may allow the learner to use learning resources in the content package, based on how other learning resources of the same package have been used in past activities.

            In the past, CBT authoring tools typically provided custom sequencing and navigation features that were encoded in proprietary data formats. However, new requirements emerged, such as the ability to publish and deploy browser-based content through different LMS systems. Another requirement was to be able to separate structure and instructional strategy logic from the learning resource used in implementing the strategy. This led to the need to standardize some means to define and encode adaptive sequencing and navigation behaviors, so that content organizations can be moved, used and reused across different LMS environments.

            The standardization process for sequencing and navigation has proved difficult due to the variety of complex design approaches required in order to effectively train certain tasks or prepare learners for complex roles or responsibilities. Past versions of SCORM provided no specific sequencing capabilities, effectively allowing only pure free play, because it is a difficult and complex subject that required more time to come up with workable solutions. There are many, and often divergent, requirements in the learning design community. No approach has been found to solve everyone’s use case. However, the approach used in SCORM, which is based on the IMS SS Specification [5], is flexible enough to allow a wide variety of learning and instructional design approaches.

            Section 5: SCORM Sequencing and Navigation describes how the sequencing and navigation rules are embedded into the XML representation of content organizations in a package manifest, in compliance with the IMS SS Specification and SCORM. This specification enables robust sequencing and navigation information to be associated with content packages extending the content organization schema with sequencing prescriptions. These prescriptions are based on a common model for expressing rules, events and conditions as well as run-time behaviors associated with various sequencing and navigation methods.


            The IMS SS Specification enables systems to deliver learning resources in a predictable manner, while reacting consistently to learners’ interactions with learning resources. The intended approach fosters reusability of learning resources by allowing content developers to define sequencing and navigation behavior or instructional strategies independently of the actual learning resources. The adaptive sequencing information is encoded in the content organization, allowing learning resources to be reused in multiple contexts (i.e. multiple different manifests or organizations, each having their own set of sequencing and navigation information).

      3. Resources

        The resources component of a manifest can describe external resources, as well as the physical files located in the package. These files may be media files, text files, assessment objects or other pieces of data in electronic form. Conceptual groupings and relationships between files can be represented within the resources component. The combination of resources is generally categorized as “content.” The resources are referred to at various points within the organizations component, which provides the structure for the resources.

        Resource

        GIF

        JPEG

        HTML

        Resource

        GIF


        JPEG

        Flash

        Resources

Resource

GIF

Flash


HTML

JavaScript

Resource

HTML

JPEG

JavaScript

JavaScript

In Figure 3.3.3a, a single Resource is made up of multiple components. In SCORM, these components are simple assets. If the Resource was built to communicate with an LMS (See SCORM Run-Time Environment book [2]) then the Resource is a SCO. If the Resource was not built to communicate with an LMS the Resource is considered an Asset. The collection of Resource components makes up the Resources that an Organization can refer to. This collection of Resources and the Organization defines the Content Organization.



Figure 3.3.3a: Manifest Resources

The Resource describes the physical makeup (inventory of components) of the resource as a whole. The components of the resource are listed as Files within the Resource.


      1. Physical Files

        The physical files component represents the actual files referenced in the resources component. These files may be local files that are actually contained within the content package, or they can be external files that are referenced by a Universal Resource Indicator (URI).


    1. Building Content Packages

      This section presents the requirements for building SCORM Content Packages. The section describes the XML binding for the IMS Content Packaging Specification as applied to SCORM. There are some specific rules that have guided the creation of this XML binding:

      • The XML binding will adhere to the XML 1.0 specification [6] of the W3C; and

      • The XML binding must maintain the definitional structure of the IMS Content Packaging Information Model.

      Some of the requirements are also drawn from other various specifications and standards. The majority of the requirements are inherited by the requirements defined in IMS Content Packaging Specification. Some other specifications and standards are implicitly inherited based on the nature of the XML and other Internet technologies.

      This section also defines the requirements for each of the SCORM Content Package Application Profiles:

      • Resource Package Application Profile: A content package for bundling a set of learning resources with no defined organization of the learning resources (SCOs and Assets). These learning resources do not have to have any relationship between them.

      • Content Aggregation Package Application Profile: A content package for bundling a set of learning resources and their intended static structure and sequencing requirements (i.e., the manifest contains 1 or more organizations of the learning resources).

      Refer to Section 3.5: The SCORM Content Package Application Profiles for more information on SCORM Content Package Application Profiles.


      1. Manifest File

        The following section defines the requirements for building an imsmanifest.xml file. The manifest is a structured inventory of the content of the package. If the package is intended for delivery to an end user, then the manifest also contains information about how the content is organized. The imsmanifest.xml is, as the name implies, an XML file. This section defines the requirements for each element defined by the IMS Content Packaging Specification.

        Some elements use the term smallest permitted maximum (SPM) in describing the multiplicity and/or data types. The SPM indicates that applications that process content packages shall process at least that number of elements or number of characters, but are free to support and exceed the limit.

        The data types and the formats for the elements are defined by the data types prescribed by the XML Schema Part 2: Datatypes W3C Recommendation [13]. The ordering of the XML elements is as defined by the IMS Content Packaging XML Binding for the manifest.

        The following table is used to describe the SCORM Content Packaging Application Profile (refer to Section 3.5 for more details) requirements:


        Table 3.4.1a: SCORM Content Packaging Application Profile Table Format


        SCORM Content Packaging Application Profile

        Manifest Multiplicity Requirements

        Content Aggregation

        <requirement>

        Resource

        <requirement>


        The left-hand column is titled SCORM Content Packaging Application Profile. This column describes the types of application profiles defined by SCORM. The right-hand column is titled Manifest Multiplicity Requirements. This column defines the multiplicity requirement for the XML elements in the imsmanifest.xml file.


        Table 3.4.1b: Explanation of Multiplicity Requirements


        Multiplicity Requirement

        Explanation

        1 and only 1

        The element must exist 1 and only 1 time within the parent element

        0 or More

        The element can exist 0 or More times within the parent element.

        1 or More

        The element must exist 1 or More times within the parent element.

        0

        The element is not permitted.

        0 or 1

        The element can exist 0 or 1 time within the parent element.


        Table 3.4.1b defines the types of multiplicities that are used in this section. Each type is accompanied by a brief explanation.


        1. <manifest> Element

          The <manifest> element represents a reusable unit of instruction that encapsulates meta- data, organizations and resource references [3]. The <manifest> element is the root element node in the imsmanifest.xml file. Subsequent occurrences of the <manifest> elements inside the root <manifest> are used to compartmentalize files, meta-data and organization structure for aggregation, disaggregation and reuse. These child

          <manifest> elements are referred to as (sub)manifests. (Sub)Manifests are described in more detail in Section 3.4.2: (Sub)Manifests.

          All namespace declarations should be declared inside the <manifest> element. This includes any namespaces that are considered extensions to IMS and ADL. Although this is not considered a requirement, based on the XML specifications, ADL considers this to be a “best practice” and urges vendors and tools to provide this information.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <manifest>

          SCORM Requirements: The manifest element is the root element node for an IMS Manifest. The root <manifest> element shall exist 1 and only 1 time.


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          1 and only 1

          Data Type: The <manifest> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <manifest> element contains the following elements/attributes:.

          Attributes:

Code Illustration 3-1


        1. <metadata> Element

          The <metadata> element contains meta-data describing the manifest [3]. It contains relevant information that describes the content package (i.e., Content Aggregation) as a whole. The <metadata> element is considered the root node for meta-data defined in a content package. This means that all meta-data for a content package is defined as a child of the <metadata> element.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <metadata>

          SCORM Requirements: SCORM places a requirement that all <manifest> elements shall contain the following multiplicity requirements for the <metadata> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          1 and only 1

          Data Type: The <metadata> element is a parent element. Parent elements have no values associated with them. Parent element acts as “containers” for other elements/attributes. The <metadata> element contains the following elements/attributes:

          Attributes:

          • None

          Elements:

          • <schema>

          • <schemaversion>

          • {Meta-data}

          Example:

          <manifest identifier="SAMPLE1" version="1.3" xml:base="mycontent/" xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1

          imscp_v1p1.xsd http://www.adlnet.org/xsd/adlcp_v1p3 adlcp_v1p3.xsd">

          <metadata>

          <schema>ADL SCORM</schema>

          <schemaversion>CAM 1.3</schemaversion>

          <adlcp:location>packageMetadata.xml</adlcp:location>

          </metadata>

          </manifest>

Code Illustration 3-2


        1. <schema> Element

          The <schema> element describes the schema that defines and controls the Manifest [3]. Since this element is a child of the meta-data describing the package, the element is used to describe the schema that controls the requirements of the manifest.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <schema>

          SCORM Requirements: SCORM places a requirement that the <schema> element shall adhere to the following multiplicity requirements:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          1 and only 1

          Data Type: The <schema> element is represented as a characterstring. XML Data Type:

          xs:string.

          SCORM requires that the <schema> element contain the following restricted vocabulary token:

          • ADL SCORM: This restricted token indicates that the Content Package is built in accordance with the requirements defined by SCORM.

          Example:


          <manifest>

          <metadata>

          <schema>ADL SCORM</schema>

          <schemaversion>CAM 1.3</schemaversion>

          </metadata>

          </manifest>

Code Illustration 3-3


        1. <schemaversion> Element

          The <schemaversion> element describes the version of the above schema (<schema>) [3].

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <schemaversion>

          SCORM Requirements: SCORM places a requirement that the <schemaversion>

          Manifest Multiplicity Requirements

          element shall adhere to the following multiplicity requirements:


          SCORM Content Packaging Application Profile


          Content Aggregation

          1 and only 1

          Resource

          1 and only 1

          Data Type: The <schemaversion> element is represented as a characterstring. XML Data Type: xs:string.

          SCORM requires that the <schemaversion> element contain the following restricted vocabulary token:

          • CAM 1.3: This restricted token indicates that the Content Package is built in accordance with SCORM Content Aggregation Model Version 1.3.

          Example:


          <manifest>

          <metadata>

          <schema>ADL SCORM</schema>

          <schemaversion>CAM 1.3</schemaversion>

          </metadata>

          </manifest>

Code Illustration 3-4

        1. {Meta-data}

          Meta-data can be inserted into a manifest using an appropriate meta-data scheme [3]. If using meta-data to describe SCORM Content Model Components, ADL highly recommends, at a minimum, the use of the IEEE LOM meta-data scheme. Organizations may use various other meta-data schemes if necessary (e.g., Dublin Core). This meta- data describes the package as a whole (Content Aggregation meta-data). There are several mechanisms for inserting meta-data in a manifest. Meta-data can be inserted into a manifest by extensions to the XML (inline meta-data). ADL also provides a namespaced element (Refer to Section 3.4.1.5.2: < location> Element) to permit a reference to a stand-alone XML file. The {Meta-data}, found as a child of the

          <manifest>, is optional (can appear 0 or More times using one of the mechanisms described). The example below illustrates the use of inline XML extensions of the LOM elements.

          1. Meta-data using XML extensions

            By definition, XML can be extended by introducing elements and attributes from other defined namespaces. Meta-data can be inserted into the Content Package manifest by using this type of XML extension mechanism. There are several ways to add extension elements into an XML document:

            1. Defining a namespace in an XML element with a specific prefix. In this method, the specific namespace must be defined using the xmlns:<prefix> syntax in the element. Typically, these prefixes are defined in the root node of an XML element. However, this is not a requirement. The prefix and namespace can be defined in any element, as long as the extended elements are not used prior to the declaration of the namespace (refer to Code Illustration 3-5 for an example)

              Example:


              <manifest xmlns:lom = "http://ltsc.ieee.org/xsd/LOM">

              <metadata>

              <schema>ADL SCORM</schema>

              <schemaversion>CAM 1.3</schemaversion>

              <lom:lom>

              <lom:general>

              <lom:title>

              <lom:string language="en-US">Title for the Package</lom:string>

              </lom:title>

              </lom:general>

              <lom:metaMetadata>

              <lom:metadataSchema>LOMv1.0</lom:metadataSchema>

              <lom:metadataSchema>SCORM_CAM_v1.3</lom:metadataSchema>

              </lom:metaMetadata>

              </lom:lom>

              </metadata>

              </manifest>

Code Illustration 3-5

            1. Defining a namespace in an XML element without a prefix. In this method, the namespace is defined at the point of use. By using this method, the syntax is

              stating that the element is from a particular namespace and every child element of this element is also from the namespace (refer to Code Illustration 3-6 for an example).

              Example:


              <manifest>

              <metadata>

              <schema>ADL SCORM</schema>

              <schemaversion>CAM 1.3</schemaversion>

              <lom xmlns="http://ltsc.ieee.org/xsd/LOM">

              <general>

              <title>

              <string language="en-US">Title for the Package</string>

              </title>

              </general>

              <metaMetadata>

              <metadataSchema>LOMv1.0</metadataSchema>

              <metadataSchema>SCORM_CAM_v1.3</metadataSchema>

              </metaMetadata>

              </lom>

              </metadata>

              </manifest>

Code Illustration 3-6

          1. <location> Element

            The <location> element provides a means to describe the location where the meta-data describing the SCORM Content Model Component may be found. This may be a URI. This is an ADL namespaced element extension to the IMS Content Packaging Specification. The meta-data creator has two options for expressing meta-data in a Content Package. The creator can either use the <location> element to express the location of the meta-data record or place the meta-data inline within the Manifest file, as described previously. This value is affected by the use of xml:base values. Refer to Section 3.4.4.1: Handling the XML Base Attribute for more information on xml:base usage requirements and guidance.

            XML Namespace: http://www.adlnet.org/xsd/adlcp_v1p3

            XML Namespace Prefix: adlcp

            XML Binding Representation: <location>

            SCORM Requirements: SCORM places a requirement that the <adlcp:location>

            element shall adhere to the following multiplicity requirements:


            SCORM Content Packaging Application Profile

            Manifest Multiplicity Requirements

            Content Aggregation

            0 or More

            Resource

            0 or More

            Data Type: The <adlcp:location> element is represented as a characterstring. The characterstring has an SPM of 2000 characters. XML Data Type: xs:string.

            Attributes:

            • None

              Elements:

            • None

            Example:


            <manifest>

            <metadata>

            <schema>ADL SCORM</schema>

            <schemaversion>CAM 1.3</schemaversion>

            <adlcp:location>course/metadata/course.xml</adlcp:location>

            </metadata>

            </manifest>

Code Illustration 3-7


        1. <organizations> Element

          The <organizations> element describes one or more structures or organizations for the content package [3].

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <organizations>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <organizations> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          1 and only 1

          SCORM places a requirement that when building a Resource Package, this element is required to be represented in the manifest as an empty element (i.e., <organizations/>). When building a Content Aggregation Package, this element is required to contain at least one <organization> sub-element.

          Data Type: The <organizations> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <organizations> element contains the following elements/attributes:

          Attributes:

          • default (mandatory – for a Content Aggregation Package) – The default attribute identifies the default organization to use. The value of this element must reference an identifier attribute of an <organization> element that is a direct descendent of the <organizations> element. XML Data Type: xs:IDREF.

            Elements:

          • <organization>

          Example:

          <organizations default="TOC1">

          <organization identifier="TOC1">

          <title>Introduction to SCORM for LMS Vendors</title>

          <!--organizations structure placed here -->

          </organization>

          <organization identifier="TOC2">

          <title>Introduction to SCORM for Content Vendors</title>

          <!--organizations structure placed here -->

          </organization>

          </organizations>

Code Illustration 3-8

        1. <organization> Element

          The <organization> element describes a particular hierarchical organization [3]. The content organization is defined by the <organization> element. The content organization is a conceptual term. The content organization can be a lesson, module, course, chapter, etc. What a content organization defines is dependent on an organization’s curricular taxonomy. The <organization> element represents an Activity in the terms of IMS SS.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <organization>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <organization> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 or More

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element (its parent) is required to be empty.

          Data Type: The <organization> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <organization> element contains the following elements/attributes:

          Attributes:

          • identifier (mandatory) – An identifier for the organization that is unique within the manifest file [3]. Typically this value is provided by an author or authoring tool. XML Data Type: xs:ID.

          • structure (optional) – Describes the shape of the organization [3]. The default value of the structure attribute, if not provided, shall be hierarchical. The value has an SPM of 200 characters. XML Data Type: xs:string.

          • adlseq:objectivesGlobalToSystem (optional, default = true) – This attribute indicates that any mapped global shared objectives defined in sequencing information (Refer to Section 5.1.1: <sequencing> Element) are either global to the learner and the content organization (false) or global for the lifetime of the learner within the LMS (true) across all content organizations. XML Data Type: xs:boolean.

            Elements:

          • <title>

          • <item>

          • <metadata>

          • <imsss:sequencing>

          Example:


          <organizations>

          <organization identifier="TOC1">

          <title> Introduction to SCORM for LMS Vendors </title>

          <item identifier="ITEM1" identifierref="RESOURCE1" isvisible="true">

          <title>SCORM Run-Time Environment Requirements</title>

          </item>

          <item identifier="ITEM2" identifierref="RESOURCE2" isvisible="true">

          <title>LMS Conformance Requirements</title>

          </item>

          </organization>

          </organizations>

Code Illustration 3-9


        1. <title> Element

          The <title> element describes the title of the organization [3]. This element could be used to help a learner decide which organization to choose. Depending on what the organization is describing, this title could be for a course, module, lesson, etc.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <title>

          SCORM Content Packaging Application Profile

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <title> element:



          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <title> element is represented as a characterstring element. The characterstring has an SPM of 200 characters. XML Data Type: xs:string.

          Example:


          <organization identifier="TOC1">

          <title>Introduction to the SCORM</title>

          </organization>

Code Illustration 3-10

        1. <item> Element

          The <item> element is a node that describes the hierarchical structure of the organization [3]. The <item> element represents an Activity in the content organization. The <item> element describes a node within the organization’s structure. The <item> element can be nested and repeated within other <item> elements to any number of levels. This structuring of <item> elements shapes the content organization and describes the relationships between parts of the learning content.

          The <item> element can act as a container of other <item> elements or as a leaf node. If an <item> is a leaf node, then the <item> shall reference a <resource> element. If an

          <item> element is a parent element, the <item> itself is not permitted to reference a

          <resource> element (only leaf <item> elements are permitted to reference resources).

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <item>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <item> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 or More

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <item> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <item> element contains the following elements/attributes:

          Attributes:

          • identifier (mandatory) – An identifier attribute is an identifier, for the item, that is unique within the Manifest. XML Data Type: xs:ID.

          • identifierref (optional) – The identifierref attribute is a reference to an identifier in the resources section or a (sub)manifest [3]. The identifierref is permitted to reference an identifier of a <resource> (within the same manifest), an identifier of a <resource> (within a (sub)manifest that is in scope of the containing manifest) or an identifier of a (sub)manifest. The (sub)manifest is used to resolve the ultimate location of the file. If no identifierref is supplied, it is assumed that there is no content associated with this entry in the organization. The value has an SPM of 2000 characters. XML Data Type: xs:string.

          • isvisible (optional) – The isvisible attribute indicates whether or not this item is displayed when the structure of the package is displayed or rendered. If

            not present, value is defaulted to be true [3]. The value only affects the item for which it is defined and not the children of the item or a resource associated with an item. XML Data Type: xs:boolean.

            • parameters (optional) – The parameters attribute contains the static parameters to be passed to the resource at launch time. The parameters attribute should only be used for <item> elements that reference <resource> elements. The value has an SPM of 1000 characters. XML Data Type: xs:string.

              Elements:

            • <title>

            • <item>

            • <metadata>

            • <adlcp:timeLimitAction>

            • <adlcp:dataFromLMS>

            • <adlcp:completionThreshold>

            • <imsss:sequencing>

            • <adlnav:presentation>

          Example:


          <organization>

          <item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true" parameters="?width=500&#038;length=300">

          <title>Content 1</title>

          </item>

          </organization>

Code Illustration 3-11


        1. <title> Element

          The <title> element describes the title of the item [3].

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <title>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <title> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty. Consequently, no <item> or <title> will be provided.

          Data Type: The <title> element is represented as a characterstring element. The characterstring has an SPM of 200 characters. XML Data Type: xs:string.

          Example:


          <organization>

          <item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">

          <title>Content 1</title>

          </item>

          </organization>

Code Illustration 3-12


        1. <item> Element

          The <item> element can be nested an arbitrarily number of levels. This is typically based on the content structure of the aggregation. The <item> element can appear 0 or More times as a child of an <item> element. Refer to Section 3.4.1.9 for more details on the

          <item> element.


        2. <metadata> Element

          The <metadata> element contains meta-data describing the item [3]. SCORM defines the meta-data that is used to describe the <item> as Activity Meta-data. Refer to Section

          4.5.1.3: Activity Meta-data for the SCORM Activity Meta-data Application Profile requirements. The <metadata> element is considered the root node for meta-data describing the activity. This means that all meta-data for the activity is defined as a child of the <metadata> element.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <metadata>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <metadata> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <metadata> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <metadata> element contains the following elements/attributes:

          Attributes:

          • None

            Elements:

            • {Meta-data} – Refer to Section 3.4.1.5: {Meta-data} for information on the inclusion of meta-data.

              ADL Note: This is different from the <metadata> element defined in Section 3.4.1.2:

              <metadata> Element. The IMS Content Packaging Specification only permits the

              <schema> and <schemaversion> elements on the <metadata> element defined as a child of the <manifest> element.

              Example:

              <organization>

              <item>

              <title>The organization title</title>

              <metadata>

              <adlcp:location>lesson1/lesson1MD.xml</adlcp:location>

              </metadata>

              </item>

              </organization>

Code Illustration 3-13


        1. <timeLimitAction> Element

          The <timeLimitAction> element defines the action that should be taken when the maximum time allowed in the current attempt of the activity is exceeded. All time tracking and time limit actions are controlled by the SCO.

          This element is an ADL defined extension to the IMS Content Packaging Specification. The element shall only appear, if needed, as a child of a leaf <item> element that references a SCO. Only those <item> elements that reference a SCO resource can contain the <timeLimitAction> element.

          The LMS shall use the value of the <timeLimitAction> element, if provided, to initialize the cmi.time_limit_action data model element (Refer to SCORM Run-Time Environment book [2]). If the content developer defines a time limit action, then the SCO is responsible for all behaviors based on the time out (if the time out occurs).

          XML Namespace: http://www.adlnet.org/xsd/adlcp_v1p3

          XML Namespace Prefix: adlcp

          XML Binding Representation: <timeLimitAction>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <timeLimitAction> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <timeLimitAction> element is represented as a characterstring. The characterstring is required to be one of following set of restricted characterstring tokens:

          • exit,message: The learner should be forced to exit the SCO. The SCO should provide a message to the learner indicating that the maximum time allowed for the learner attempt was exceeded.

          • exit,no message: The learner should be forced to exit the SCO with no message.

          • continue,message: The learner should be allowed to continue in the SCO. The SCO should provide a message to the learner indicating that the maximum time allowed for the learner attempt was exceeded.

          • continue,no message: Although the learner has exceeded the maximum time allowed for the learner attempt, the learner should be given no message and should not be forced to exit the SCO.

          If this feature is used within the SCO, the SCO shall keep track of the time affecting this timeout period and provide the informative message indicating the timeout (if appropriate).

          Example:


          <organization>

          <item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">

          <title>Content 1</title>

          <adlcp:timeLimitAction>exit,no message</adlcp:timeLimitAction>

          </item>

          </organization>

Code Illustration 3-14


        1. <dataFromLMS> Element

          The <dataFromLMS> element provides initialization data expected by the resource (i.e., SCO) represented by the <item> after launch. This data is opaque to the LMS and only has functional meaning to the SCO. This element shall not be used for parameters that the SCO may need during the launch (query string parameters). If this type of functionality is required, then the developer should use the parameters attribute of the item referencing the SCO resource.

          This element is an ADL defined extension to the IMS Content Packaging Specification. The element shall only appear, if needed, as a child of a leaf <item> element. Only those

          <item> elements that reference a SCO resource can contain the <dataFromLMS>

          element).

          The LMS shall use the value of the <dataFromLMS> element, if provided, to initialize the

          cmi.launch_data data model element (See SCORM Run-Time Environment book [2]).

          XML Namespace: http://www.adlnet.org/xsd/adlcp_v1p3

          XML Namespace Prefix: adlcp

          XML Binding Representation: <dataFromLMS>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <dataFromLMS> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <dataFromLMS> element is represented as a characterstring element. The characterstring has an SPM of 4096 characters.

          Example:


          <organization>

          <item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">

          <title>Content 1</title>

          <adlcp:dataFromLMS>Some SCO Information</adlcp:dataFromLMS>

          </item>

          </organization>

Code Illustration 3-15


        1. <completionThreshold> Element

          The <completionThreshold> element defines a threshold value that can be used by the SCO resource referenced by the <item> for which the <completionThreshold> is defined. This element is an ADL defined extension to the IMS Content Packaging Specification. The element shall only appear, if needed, as a child of a leaf <item> element. Only those <item> elements that reference a SCO resource can contain the

          <completionThreshold> element).

          The LMS shall use the value of the <completionThreshold> element, if provided, to initialize the cmi.completion_threshold data model element (See SCORM Run-Time Environment book [2]).

          XML Namespace: http://www.adlnet.org/xsd/adlcp_v1p3

          XML Namespace Prefix: adlcp

          XML Binding Representation: <completionThreshold>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <completionThreshold> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <completionThreshold> element is represented as a decimal value between the range of 0.0 and 1.0 element.

          Example:


          <organization>

          <item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">

          <title>Content 1</title>

          <adlcp:completionThreshold>0.75</adlcp:completionThreshold>

          </item>

          </organization>

Code Illustration 3-16


        1. <sequencing> Element

          Refer to Section 5.1.1: <sequencing> Element.


        2. <presentation> Element

          Refer to Section 5.2.1.1: <presentation> Element.


        3. <metadata> Element

          The <metadata> element is meta-data describing the organization [3]. SCORM defines the meta-data that is used to describe the <organization> as Content Organization Meta-data. Refer to Section 4.5.1.2: Content Organization Meta-data for the SCORM Content Organization Meta-data Application Profile requirements. The <metadata> element is considered the root node for meta-data describing the content organization.

          This means that all meta-data for the content organization is defined as a child of the

          <metadata> element.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <metadata>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for this <metadata> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0

          For Resource Packages, this element shall not appear. The <organizations> element is required to be empty.

          Data Type: The <metadata> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <metadata> element contains the following elements/attributes:

          Attributes:

          • None

            Elements:

          • {Meta-data} – Refer to Section 3.4.1.5: {Meta-data} for information on the inclusion of meta-data.

          ADL Note: This is different from the <metadata> element defined in Section 3.4.1.2:

          <metadata> Element. The IMS Content Packaging Specification only permits the

          <schema> and <schemaversion> elements on the <metadata> element defined as a child of the <manifest> element.

          Example:

          <organization>

          <title>Introduction to SCORM</title>

          <item identifier="ITEM1" identifierref="RESOURCE1" isvisible="true">

          <title>SCORM Run-Time Environment Requirements</title>

          </item>

          <metadata>

          <adlcp:location>activities/activity1MD.xml</adlcp:location>

          </metadata>

          </organization>

Code Illustration 3-17


        1. <sequencing> Element

          Refer to Section 5.1.1: <sequencing> Element.


        2. <resources> Element

          The <resources> element is a collection of references to resources. There is no assumption of order or hierarchy of the individual <resource> elements that the

          <resources> element contains [3].

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <resources>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <resources> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          1 and only 1

          Resource

          1 and only 1

          Data Type: The <resources> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <resources> element contains the following elements/attributes:

          Attributes:

          • xml:base (optional) – The xml:base attribute provides a relative path offset for the content file(s) [3]. The usage of this element is defined in the XML Base [7] Working Draft from the W3C. The value has an SPM of 2000 characters. XML Data Type: xs:anyURI.

            Elements:

          • <resource>

          Example:


          <manifest>

          <metadata/>

          <organizations/>

          <resources>

          <resource identifier="RESOURCE1" type="webcontent" href="lesson1.htm">

          <file href="lesson1.htm"/>

          </resource>

          <resource identifier="RESOURCE2" type="webcontent" href="intro1.htm">

          <file href="intro1.htm"/>

          </resource>

          <resource identifier="RESOURCE3" type="webcontent" href="content1.htm">

          <file href="content1.htm"/>

          </resource>

          <resource identifier="RESOURCE4" type="webcontent" href="summary1.htm">

          <file href="summary1.htm"/>

          </resource>

          </resources>

          </manifest>

Code Illustration 3-18


        1. <resource> Element

          The <resource> element is a reference to a resource [3]. There are two primary types of resources defined within SCORM:

          • SCOs

          • Assets

            XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

            XML Namespace Prefix: imscp

            XML Binding Representation: <resource>

            SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <resource> element:


            SCORM Content Packaging Application Profile

            Manifest Multiplicity Requirements

            Content Aggregation

            0 or More

            Resource

            0 or More

            A leaf <item> element is required to reference a resource (SCO resource or Asset resource). If an <item> references a resource, this resource is subject to being identified for delivery and launch to the learner. If an <item> references a <resource> the resource shall meet the following requirements:

          • The type attribute shall be set to webcontent

          • The adlcp:scormType shall be set to sco or asset

          • The href attribute shall be required.

            Data Type: The <resource> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <resource> element contains the following elements/attributes:

            Attributes:

          • identifier (mandatory) – The identifier attribute represents an identifier, of the resource, that is unique within the scope of its containing manifest file [3]. This identifier is typically provided by an author or authoring tool. XML Data Type: xs:ID.

          • type (mandatory) – The type attribute indicates the type of resource [3]. The value has an SPM of 1000 characters. XML Data Type: xs:string.

          • href (optional) – The href attribute is a reference a Uniform Resource Locator (URL) [3]. The href attribute represents the “entry point” or “launching point” of this resource. External fully qualified URLs are also permitted. This value is affected by the use of xml:base values. Refer to Section 3.4.4.1: Handling the XML Base Attribute for more information on xml:base usage requirements and guidance. The value has an SPM of 2000 characters. XML Data Type: xs:string.

          • xml:base (optional) – The xml:base attribute provides a relative path offset for the files contained in the manifest. The usage of this element is defined in the XML Base Working Draft from the W3C. The value has an SPM of 2000 characters. XML Data Type: xs:anyURI.

          • adlcp:scormType (mandatory) – The adlcp:scormType attribute defines the type of SCORM resource. This is an ADL extension to the IMS Content Packaging Information Model. XML Data Type: xs:string. The character string is restricted and shall be one of the following characterstring tokens ( sco or asset). Where sco indicates that the resource is a SCO resource and asset indicates that the resource is a Asset resource.

          • adlcp:persistState (optional) – The adlcp:persistState attribute provides a means to persist data from learner attempt to learner attempt. As described in the SCORM Run-Time Environment book [2], when a new learner attempt is initiated a new set of run-time data is provided (i.e., a blank slate of data, default values apply). If the adlcp:persistState attribute is defined and set to true, then the old learner attempt data shall be used for initializing the new learner attempt. XML Data Type: xs:boolean. The default value, if no attribute is provided, is false.

            Elements:

          • <metadata>

          • <file>

          • <dependency>


          Example:


          <resources>

          <resource identifier="R_A2" type="webcontent" adlcp:scormType="sco" adlcp:persistState="true" href="sco1.html">

          <file href="sco1.html"/>

          </resource>


          <!-- adlcp:persistState is not defined, default value of false should be applied -->

          <resource identifier="R_A3" type="webcontent" adlcp:scormType="sco" href="sco3.html">

          <file href="sco3.html"/>

          </resource>


          <resource identifier="R_A5" type="webcontent" adlcp:scormType="asset" href="pics\distress_sigs_add.jpg">

          <file href="pics\distress_sigs_add.jpg"/>

          </resource>

          </resources>

Code Illustration 3-19


        1. <metadata> Element

          The <metadata> element is meta-data describing the resource [3]. SCORM defines the meta-data that is used to describe the <resource> as either SCO Meta-data or Asset Meta-data. This depends on the SCORM type (adlcp:scormType) of resource. Refer to Section 4.5.1: Associating Meta-data with SCORM Components for the SCORM SCO and Asset Meta-data Application Profile requirements. The <metadata> element is

          considered the root node for meta-data describing the resource. This means that all meta- data for the resource is defined as a child of the <metadata> element.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <metadata>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <metadata> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0 or 1

          Data Type: The <metadata> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <metadata> element contains the following elements/attributes:

          Attributes:

          • None

            Elements:

          • {Meta-data} – Refer to Section 3.4.1.5: {Meta-data} for information on the inclusion of meta-data.

          ADL Note: This is different from the <metadata> element defined in Section 3.4.1.2:

          <metadata> Element. The IMS Content Packaging Specification only permits the

          <schema> and <schemaversion> elements on the <metadata> element defined as a child of the <manifest> element.

          Example:

          <resources>

          <resource identifier="R_A2" type="webcontent" adlcp:scormType="sco" href="sco1.html">

          <file href="sco1.html"/>

          <metadata>

          <adlcp:location>resources/resource1MD.xml</adlcp:location>

          </metadata>

          </resource>

          </resources>

Code Illustration 3-20


        1. <file> Element

          The <file> element is a listing of files that this resource is dependent on [3]. This element is repeated as necessary for each file for a given resource. The element acts as an inventory system detailing the set of files used to build the resource. The <file>

          element represents files that are local to the content package. For all files that are local to the content package (physically located in the content package), a <file> element shall be used to represent the file relative to the resource in which it is used. If the resource identified is local to the package, then the resource itself shall be identified as a <file> element. The launch location of the <resource> (<resource>’s href value) shall be used as the href of the file.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <file>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <file> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or More

          Resource

          0 or More

          Data Type: The <file> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <file> element contains the following elements/attributes:

          Attributes:

          • href (mandatory) – The href attribute identifies the location of the file [3]. This value is affected by the use of xml:base values. Refer to Section 3.4.4.1: Handling the XML Base Attribute for more information on xml:base usage requirements and guidance. The value has an SPM of 2000 characters. XML Data Type: xs:string.

            Elements:

          • <metadata>

          Example:


          <resource identifier="R_A2" type="webcontent" adlcp:scormType="sco" href="sco1.html">

          <file href="assets/image1.gif"/>

          <file href="sco1.html"/>

          <file href="assets/common/APIWrapper.js"/>

          </resource>

Code Illustration 3-21


        1. <metadata> Element

          The <metadata> element is meta-data describing the file [3]. SCORM defines the meta- data that is used to describe the <file> as Asset Meta-data. Refer to Section 4.5.1.5: Asset Meta-data for the SCORM Asset Meta-data Application Profile requirements. The

          <metadata> element is considered the root node for meta-data describing the Asset. This means that all meta-data for the Asset is defined as a child of the <metadata> element.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <metadata>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <metadata> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or 1

          Resource

          0 or 1

          Data Type: The <metadata> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements/attributes. The <metadata> element contains the following elements/attributes:

          Attributes:

          • None

            Elements:

          • {Meta-data} – Refer to Section 3.4.1.5: {Meta-data} for information on the inclusion of meta-data.

          ADL Note: This is different from the <metadata> element defined in Section 3.4.1.2:

          <metadata> Element. The IMS Content Packaging Specification only permits the

          <schema> and <schemaversion> elements on the <metadata> element defined as a child of the <manifest> element.

          Example:

          <resource identifier="R_A2" type="webcontent" adlcp:scormType="sco" href="sco1.html">

          <file href="assets/image1.gif">

          <metadata>

          <adlcp:location>assets/asset1.xml</adlcp:location>

          </metadata>

          </file>

          <file href="sco1.html"/>

          <file href="assets/common/APIWrapper.js"/>

          </resource>

Code Illustration 3-22


        1. <dependency> Element

          The <dependency> element identifies a resource whose files this resource (the resource in which the dependency is declared in) depends on [3]. The resource that the

          <dependency> references can act as a container for multiple files that the resource containing the <dependency> is reliant on.

          XML Namespace: http://www.imsglobal.org/xsd/imscp_v1p1

          XML Namespace Prefix: imscp

          XML Binding Representation: <dependency>

          SCORM Requirements: SCORM places a requirement that all manifests shall adhere to the following multiplicity requirements for the <dependency> element:


          SCORM Content Packaging Application Profile

          Manifest Multiplicity Requirements

          Content Aggregation

          0 or More

          Resource

          0 or More

          Data Type: This element is represented as an empty element. The <dependency>

          element only contains attributes.

          Attributes:

          • identifierref (mandatory) – The identifierref attribute references an identifier attribute of a <resource> (within the same package) or a (sub)manifest and is used to resolve the ultimate location of the dependent resource. The value has an SPM of 2000 characters. XML Data Type: xs:string.

            Elements:

          • None


          Example:


          <resources>

          <resource identifier="R_A2" type="webcontent" adlcp:scormType="sco" href="sco1.html">

          <file href="sco1.html"/>

          <dependency identifierref="R_A5"/>

          </resource>

          <resource identifier="R_A5" type="webcontent" adlcp:scormType="asset" href="pics\distress_sigs_add.jpg">

          <file href="pics\distress_sigs_add.jpg"/>

          </resource>

          </resources>

Code Illustration 3-23


        1. <manifest> Element

          Refer to Section 3.4.1.1: <manifest> Element.

        2. <sequencingCollection> Element

Refer to Section 5.1.12: <sequencingCollection> Element.


      1. (Sub)Manifests

        One of the general rules, as described by the IMS Content Packaging Specification, is that a Content Package always contains a single top-level manifest that may contain one or more (sub)manifests. The top-level manifest always describes the contents and makeup of the Content Package. Any nested (sub)manifests describe the content at the level to which the (sub)manifest is scoped. This level could be a lesson, module, etc.

        The content developers are responsible for deciding whether or not to use (sub)manifests when creating content packages. One rule of thumb is to use a single manifest for tightly coupled content where no part of the content organization may be presented out of the context of the aggregation. Content developers may want to create separate manifests ((sub)manifests) for each lesson, module etc. This is entirely up to the content developer.

        If (sub)manifests are used there are several requirements and key points to remember. There are several ways to reference (sub)manifests from within other manifests. The following requirements are defined by the IMS Content Packaging Specification [15]. An <item> element’s identifierref attribute can reference the following:

        • A <resource> found in the current manifest.

        • A <resource> found in a subordinate <manifest> or a <resource> found in any nested <manifest> [15].

        • A sub(manifest) that is direct child of the manifest or a manifest found in any nested manifest.

          The reverse is not true: An <item> element’s identifierref cannot refer to a

          <manifest> element that is higher than the <manifest> element that contains it, or to any resource referred to by a higher-level <manifest> element [15].

          There are two references that are not permitted:

        • An <item> is not permitted to reference another <item> or an <item> in a (sub)manifest.

        • An <item> is not permitted to reference an <organization> or an

        <organization> in a (sub)manifest.

        The IMS Content Packaging Best Practice Guide describes and defines scoping rules for packages and manifests. The scoping rules are defined as a parent-child relationship.

        This means that a manifest “knows” about its (sub)manifests and any of the (sub)manifest’s child (sub)manifests.

        Figure 3.4.2a illustrates the legal reference rules described above. In the figure, an

        <item> in the manifest can reference a <manifest> that is a child of a <manifest> or a

        <manifest> that is a subsequent child of the containing manifest. The scoping rules defined basically say that a reference can go down a nesting chain:

        Manifest 1

        Manifest 1.1 (contained by Manifest 1)

        Manifest 1.1.1 (contained by Manifest 1.1)

        Manifest 1


        <organization>

        <item>

        Manifest 1.1

        <organization>

        <item>

        Manifest 1.1.1

        <organization>

        <item>


        <item>

        <item>

        <resource>

        <resource>

        <resource>

        <resource>

        <resource>

        <resource>

        <item>

        <resource>

        <resource>

        <resource>

        <resource>

        <resource>

        <resource>

        <resource>

        Package 1

The <item> can also reference a resource in the same manifest, a resource that is in scope of the current manifest in which the <item> is defined.



Figure 3.4.2a: Legal References

The IMS Specification also defines references that are illegal and should not be made. Figure 3.4.2b illustrates those types of references that are illegal:


<resource>

<resource>

<resource>

<resource>


Package 1

Manifest 1


<organization>

<item>

Manifest 1.1

<organization>

<item>

Manifest 1.1.1

<organization>

<item>


<item>

<item>

<resource>

<resource>

<item>

<resource> <resource>

<resource> <resource>

<resource> <resource>

<resource>

Figure 3.4.2b: Illegal References


        1. Item Referencing a (Sub)Manifest

          As described above, an <item> element is permitted to reference a (sub)manifest. That is, an <item> element’s identifierref is permitted to reference a (sub)manifest identifier. The only stipulation with this is that the (sub)manifest is required to follow the scoping rules defined by the IMS Content Packaging specification. The <item> can only reference (sub)manifests that are a direct descendent of the <item> element’s containing manifest.



          ID: A1

          Title: About A1

          Manifest (ID: MAN001)

          ID: A001

          Title: About A001

          Sub-manifest (ID: SUB001)

          ID: RES001

          ID: A0021

          Title: About A0021

          ID: A002 IDREF: SUB001

          ID: A00211

          Title: About A00211


          ID: RES003

          ID: A003

          Title: About A002

          ID: RES002

          ID: A00212

          Title: About A00212

          ID: RES004

          Figure 3.4.2.1a: Item referencing a (sub)manifest

          In Figure 3.4.2.1a, the <item> with the identifier A002, references (sub)manifest with the identifier SUB001 (through the identifierref attribute). In order to process the manifest correctly, the LMS is required to conceptually merge, at some point in time, the (sub)manifest with the main manifest (Manifest with the identifier of MAN001). The root node of the organization (i.e., the <organization> element itself of the (sub)manifest) shall merge with the <item> that references the (sub)manifest. Figure 3.4.2.1b, depicts the outcome of the merge.



          Manifest (ID MAN001)

          ID: A1

          Title: About A1


          ID: A001

          Title: About A001

          ID: RES001


          ID: A0021

          Title: About A0021

          ID: A00211

          Title: About A00211

          ID: RES003

          ID: A00212

          Title: About A00212

          ID: RES004


          ID: A002

          Title: About A002


          ID: RES002

Figure 3.4.2.1b: Conceptually Merged Manifest

There are certain requirements in building manifests where <item> elements reference (sub)manifests:

  1. No sequencing information, using the <imsss:sequencing> element, can be defined on a leaf <item> if that leaf <item> references a (sub)manifest. All information defined on the reference (sub)manifest <organization> should be used when the (sub)manifest is used.

  2. Title’s are not permitted on a leaf <item> if that leaf <item> references a (sub)manifest.

  3. No ADL Content Packaging namespace (i.e.,

    "http://www.adlnet.org/xsd/adlcp_v1p3") elements are permitted on a leaf

    <item> if that leaf <item> references a (sub)manifest .

  4. No ADL Navigation namespace ("http://www.adlnet.org/xsd/adlnav_v1p3") elements are permitted on a leaf <item> if that leaf <item> references a (sub)manifest.

  5. If the adlseq:objectivesGlobalToSystem is defined on an <organization> in a (sub)manifest, then this attribute shall be ignored when merging the (sub)manifest.

  6. Referenced (sub)manifests must have 1 and only 1 <organization> element. The title, sequencing information, ADL Content Packaging namespace elements and ADL Navigation (i.e., adlnav) namespace elements defined for that

<organization> are used in the merged manifest.

        1. Items Referencing Resources

          Manifest (ID: MAN001)

          ID: A1

          Title: About A1

          ID: A001

          Title: About A001

          ID: RES001

          Sub-manifest (ID:

          SUB001)

          ID: A002 IDREF: RES002

          ID: RES002

          ID: RES003

          ID: A003

          IDREF: RES003

          Item elements can also reference resources that are defined in (sub)manifests, following the scoping rules described above. There is no requirement that the referenced resource is contained within a manifest that has an <organization> element. For example, you could build a manifest that contains no <organizations> element and is only a collection of resources. Figure 3.4.2.2a illustrates this fact.



          Figure 3.4.2.2a: Referencing Resources

          In Figure 3.4.2.2a, Item A002 and Item A003 reference Resources RES002 and RES003, respectively. The (sub)manifest, SUB001, is acting as a container of resources (i.e., there is no organization defined).

          Content developers are responsible for adhering to these rules when building content packages that use (sub)manifests.


      1. Content Package Manifest Extensions

        The IMS Content Packaging Specification allows for communities to place their own namespaced elements throughout the manifest. SCORM carries this practice with a set of extensions. These sets of extensions are required to meet various requirements and to help in the application profiling of the various specifications and standards described in SCORM. The extensions are defined in three separate XML Schema Definition (XSD) files. These files are:

      2. Content Package Manifest Href Handling

        An “href” is used to describe the location of a <file> or <resource> identified in the content package manifest. This location can either be an internal URL or an external URL. According to the IMS Content Packaging Version 1.1.3 Final Specification, the value of an href is to be constructed according to the rules expressed in RFC 2396 [8].


        1. Handling the XML Base Attribute

          The XML Base [7] is a construct used to explicitly specify the base URL of a document in resolving relative URLs in links to files in a Content Package. The URLs can be prefixed by an XML Base attribute. This allows an author or authoring tool to specify and/or offset the base directory so that it is not necessary to repeat the base directory in every use of that URL.

          The default base directory is the location of the package. This concept is known as “relative to the package.” The only way to explicitly override this default base directory is to reference a file with an absolute path that is external to the package. If the file is not external to the package, any XML Base value will simply offset the default base directory. The XML Base attribute can be either:

          Trailing slashes are required to be at the end of any XML Base value. When referencing local files in the content package, the URL, including XML Base, shall not begin with a leading forward slash (“/”). As defined in RFC 2396, a path with a leading forward slash indicates the absolute path of that file. Using a leading forward slash denotes the root of

          the local host. With this in mind, the use of a leading forward slash is not permitted to minimize misinterpretation and increase portability.

          The IMS Content Packaging XML Binding Specification allows for the use of the XML Base attribute in the <manifest>, <resources> and <resource> elements.

          If the XML Base attribute is present in the <manifest> element, all URLs found within the child elements of the <manifest> element shall use the XML Base value to construct the actual href value. This includes the href values for the <resource> and <file> elements and the value held in the <adlcp:location> element.


          <manifest xml:base="Course/">

          <organizations>

          <organization>

          <item identifier="ID1" identifierref="R_ID1"></item>

          </organization>

          </organizations>

          <resources>

          <resource identifier="R_ID1"

          href="Lesson01/Topics/index.htm"></resource>

          </resources>

          </manifest>

Code Illustration 3-24

Because of the use of the XML Base attribute in the <manifest> element and an href exists within the child hierarchy of the <manifest> element, the actual href for the resource, shown in Code Illustration 3-24, is: Course/Lesson01/Topics/index.htm.

If the XML Base attribute is present in the <resources> element, all URLs found within the child elements of the <resources> element shall use the XML Base value to construct the actual href value.


<manifest>

<organizations>

<organization>

<item identifier="ID1" identifierref="R_ID1"></item>

</organization>

</organizations>

<resources xml:base="Course/Lesson01/">

<resource identifier="R_ID1" href="Topics/index.htm"></resource>

</resources>

</manifest>

Code Illustration 3-25:

Because of the use of the XML Base attribute in the <resources> element and an href exists within the child hierarchy of the <resources> element, the actual href for the resource, shown in Code Illustration 3-25, is: Course/Lesson01/Topics/index.htm

If the XML Base attribute is present in the <resource> element, all URLs found within the child elements of the <resource> element shall use the XML Base value to construct the actual href value.


<manifest>

<organizations>

<organization>

<item identifier="ID1" identifierref="R_ID1">

</item>

</organization>

</organizations>

<resources>

<resource identifier="R_ID1" xml:base="Course/Lesson01/Topics/" href="index.htm">

</resource>

</resources>

</manifest>

Code Illustration 3-26

Because of the use of the XML Base attribute in the <resource> element and an href exists within the child hierarchy of the <resource> element, the actual href for the resource, shown in Code Illustration 3-26, is: Course/Lesson01/Topics/index.htm.

If a combination of XML Base attributes is used throughout the Manifest, the value of the XML Base attribute shall be appended in the order of the hierarchy of these elements to form the actual URL. The <manifest> element’s XML Base value comes first, followed by the <resources> elements XML Base value, followed by the <resource> elements XML Base value, followed by the href attribute’s value.


<manifest xml:base="Course/">

<organizations>

<organization>

<item identifier="ID1" identifierref="R_ID1"></item>

</organization>

</organizations>

<resources xml:base="Lesson01/">

<resource identifier="R_ID1"

href="index.htm" xml:base="Topics/">

</resource>

</resources>

</manifest>

Code Illustration 3-27


Because of the use of the XML Base attributes in the <manifest>, <resources> and

<resource> elements and an href exists as an attribute of the <resource> element, the actual href for the resource, shown in Code Illustration 3-27, is: Course/Lesson01/Topics/index.htm.


        1. URL Encoding and Decoding

          In some situations the URLs used in defining the location of the files or resource may need to be encoded. RFC 2396 defines the rules and requirements for encoding URLs. Sections 2.2 through 2.4 of RFC 2396 describe how and when to encode or decode URLs. Some characters have a "structural" purpose as delimiters in a URL and may not be escaped when they serve that purpose. Those characters are:

          • "/" in the schema part of the URL, or as a separator in the path part of a URL.

          • ":" in the schema part of the URL

          • "#" as the lead character for an anchor value

          • "&" as the separator between parameters

          • "?" as the separator between the path part of a URL and the parameters

          • "=" as the separator between a parameter value and the parameter name

          • "%" as an escape indicator

          If one of those characters exists in the URL, but not for that purpose, it must be encoded (or escaped). With this in mind, it would be incorrect to take a complete URL such as "Course/Lesson/Module/Resources/bar.html" and just escape it using an ECMAScript escape function, since that would change the path separator slashes that are required for interpretation of the URL into escaped characters. On the other hand, if the value of a parameter that is included as part of the URL contains a slash character, that character must be escaped. So, escaping must be done before assembling the parts of the URL, by escaping the segments that need to be escaped and then assembling those parts with delimiters that should not be escaped.

          Additionally, double encoding shall not be used when the URL is included in a manifest. Thus the value of an href attribute for a resource shall be a string that contains a valid URL in the exact format required to launch the resource in a browser.

          Furthermore, if parameters are specified for an <item>, they shall be properly escaped for use in a URL. For example, suppose that the following parameters are needed for a particular SCO:

          • "?ratio=3/4&scale=100&label=Gilbert & Sullivan"

            The example above is not a valid parameter value because it contains illegal characters. The “/” in “3/4” needs to be escaped because it is not part of the URL and it is not used as a separator in the path. Also, the “&” in “Gilbert & Sullivan” needs to be escaped because it is not used as a separator between parameters. The correctly escaped equivalent to these parameters is:

          • "ratio=3%2F4&scale=100&label=Gilbert %26 Sullivan"

            However, the following is not correctly escaped because characters are double-escaped:

          • "ratio=3%252F4&scale=100&label=Gilbert %2526 Sullivan"

            Since manifests are implemented in XML, the XML rules for escaping must also be followed. For example, the “&” may appear in its literal form only when used within a comment, processing instruction or a CDATA section according to the XML 1.0 standard. If they are needed elsewhere, as in the above example, it must be escaped using either numeric character references or strings (“%26” or “&amp;”). The following would be the correct value to use in the parameters attribute of the item element:

          • "ratio=3%2F4%26scale=100%26label=Gilbert %26 Sullivan"

            It is permitted to escape other characters such as the “=” or the “ “ such as:

            • "ratio%3D3%2F4%26scale%3D100%26label%3DGilbert%20%26%20Sullivan"


        2. Handling the Parameters Attribute

          There may be situations where content objects require information at launch time in order for the content object to operate properly. This information is sometimes referred to as launch parameters (or query strings). There are currently two mechanisms for representing query strings in a Manifest.

          • Option 1: As part of the <resource> or <file> href attribute. The content developer can place the query string as part of the href. An example of this is:


            <resource href="foo.html?Topic=1">

            <!-- resource information -->

            </resource>

Code Illustration 3-28


<resource> element might very well be something like "scos/foo.html#xyz", while the corresponding <file> href is "scos/foo.html".

Also, note that the manifest is also an inventory of every file included in the package, including the launch file for a resource. In other words, the <file> element is an inventory entry. The <resource> element specifies how to use a particular set of files (or how to access an external resource), and the <item> element in an <organization> specifies how to use a resource in one or more places in a content organization.

If an <item> references a <resource>, it is required that the <resource> contains an href entry for launching the resource. The parameters attribute is defined as the static parameters to be passed to the resource at launch time. This allows for the ability to reference the same <resource> from different items for different purposes.

For example:


<manifest>

<!-- For brevity, elements not in question or part of the -->

<!-- example were kept simple and incomplete -->

<organizations>

<organization>

<item identifier="I01" identifierref="R_I01" parameters="?Topic=1">

</item>

</organization>

</organizations>

<resources>

<resource identifier="R_I01" href="foo.htm">

</resource>

</resources>

</manifest>

Code Illustration 3-29


In option 1, each Resource would have to be repeated in the Manifest, with parameters

defined in the href attribute.

Due to the number of ways to syntactically represent the launch parameters within the Manifest, the IMS Content Packaging Specification details an algorithm for constructing the href attribute of the resource element and the parameters consistently.


While first char of parameters is in “?&” Clear first char of parameters

If first char of parameters is “#” If URL contains “#” or “?”

Discard parameters Done processing URL

If URL contains “?” Append “&” to the URL

Else

Append “?” to the URL Append parameters to URL

Code Illustration 3-30


    1. SCORM Content Package Application Profiles

      SCORM Content Package Application Profiles describe how the IMS Content Packaging Specification will be applied within the overall context of SCORM. The application profiles provide practical guidance for implementers and define additional requirements imposed by SCORM to integrate other standards and specifications and ensure interoperability. The IMS Content Packaging Specification will be used as the basis for a SCORM Content Package. However, SCORM will impose additional requirements, above those defined by the IMS specification, to ensure sufficient information is included in each package. This will enable SCORM-conformant systems to import and export packages that can be used by other SCORM-conformant systems.

      SCORM introduces the Content Aggregation Model (Section 2.1: The SCORM Content Model Components) that defines a generalized framework for object based learning content. The components are Assets, SCOs and Content Organizations. There are currently two SCORM Content Package Application Profiles, which describe how to package Content Aggregation Model components, identified:

      • Resource Packages and,

      • Content Aggregation Packages

      The following sections describe the application profiles, the constraints imposed by SCORM and a set of recommended best practices.


      1. Resource Package

        The SCORM Resource Package Application Profile defines a mechanism for packaging Assets and SCOs without having to provide any organization, learning context or curricular taxonomy. Packaging learning resources provides a common medium for exchange. The Resource Package Application Profile should be used for moving SCOs and Assets from system to system. Since there is no organization defined in a Resource Package, no logical content structure is defined. Since no structure is defined, this type of package cannot be delivered by an LMS to the learner. The SCORM Resource Package is merely a collection of learning resources that can be transferred between learning systems.

        In many cases an Asset resource or a SCO resource will be comprised of a single file. However, there are cases where Assets and SCOs could be comprised of multiple files. The SCORM Resource Package Application Profile allows for packaging Assets and SCOs comprised of single or multiple files. Also, Assets and SCOs may be included locally in the package or may be referenced externally. Locally packaged files will be included as physical files within the overall package. When externally referenced, the Assets and SCOs will not be included as physical files within the package, but will instead be referenced by an URL.

        The following figures depict several resource packages. The examples show a sample

        imsmanifest.xml instance and how Assets and SCOs could be represented. Figure

        3.5.1a shows an example of an Asset being represented as a <file> element in an

        imsmanifest.xml instance.


        <manifest>

        <organizations/>

        <resources>

        <resource identifier=”sco01_001" adlcp:scormType=”sco” href=”lesson01/sco01.html”>

        <file href=”image1.jpg”>

        <metadata>

        <adlcp:location>lesson01/metadata/image1.xml</adlcp:location>

        </metadata>

        </file>

        </resource>

        </resources>

        </manifest>

        <resource> (“sco”)

        Asset Meta-data

        <file>

<file>

<file href=”sco01.html”/>


Figure3.5.1a: Example of an Asset represented as a <file> element

Figure 3.5.1b shows an example of an Asset being represented as a <resource> element (i.e., Asset resource) in an imsmanifest.xml instance.


<manifest>

<organizations/>

<resources>

<resource identifier=”sco01_001" adlcp:scormType=”asset”

href=”lesson01/topic01.html”>

<file href=”topic01.html”/>

<file href=”image1.jpg”/>

<metadata>

<adlcp:location>lessson01/topic01.xml</adlcp:location>

</metadata>

</resource>

</resources>

<file>

</manifest>

<resource> (“asset”)


Asset Meta-data


<file>


Figure 3.5.1b : Example of an Asset represented as a <resource> element

Figure 3.5.1c shows an example of a SCO being represented as a <resource> element in an imsmanifest.xml instance.


<manifest>

<organizations/>

<resources>

<resource identifier=”sco01_001" adlcp:scormType=”sco”

href=”lesson01/topic01.html”>

<file href=”topic01.html”/>

<file href=”image1.jpg”>

<metadata>

<adlcp:location>lesson01/image1.xml</adlcp:location>

</metadata>

</file>

<metadata>

<adlcp:location>lessson01/topic01.xml</adlcp:location>

</metadata>

</resource>

</resources>

</manifest>


<resource> (“sco”)

SCO Meta- data


<file>

<file>

Asset Meta-data


Figure 3.5.1c : Example of a SCO represented as a <resource> element


      1. Content Aggregation Package

        SCORM does not impose any requirements on the structure for content organizations. Individual content developers are free to aggregate content into any structure that provides value to them. The IMS Content Packaging Specification [3] provides a framework that includes most of the information that is needed by ADL, as well as logical places in which ADL extensions can be added to capture the rest of the information. Additionally, the IMS packaging model also provides a clean way to inventory and bundle all of the physical files required to deliver the learning resource, as well as to identify relationships between files that belong to one or more learning resources, including externally referenced resources that are not contained as physical files within a content package. The Content Aggregation Application Profile should be used to bundle learning resources and the content structure. This is the application profile that should be used to bundle complete courses, modules, lessons, etc. The Content Aggregation package’s main purpose is to be used to deliver content to an end user.

        The IMS Content Packaging Specification also enables a separation of learning resources from the way those resources can be organized, allowing for one or more uses of the same learning resources within different contexts. SCORM defines a mechanism for packaging the files and providing the structure.

        Figure 3.5.2a shows an example of a Content Organization being represented in an

        imsmanifest.xml instance.


        <manifest>

        Content Organization

        <organization identifier=”org_1">

        <item identifier=”lesson1_id1">

        <title>Introduction to SCORM</title>

        <item identifier=”lesson1_id1/topic2" identifierref=”sco01_001">

        <title>SCORM Content Model</title>

        </item>

        <!-- Content Structure Continued -->

        </item>

        </organization>

<organizations default=”org_1">

</organizations>

<resources>

<resource identifier=”sco01_001" adlcp:scormType=”sco” href=”lesson01/topic01.html”>

<file href=”topic01.html”/>

<file href=”image1.jpg”>

<metadata>

<adlcp:location>lesson01/image1.xml</adlcp:location>

</metadata>

</file>

<metadata>

<adlcp:location>lessson01/topic01.xml</adlcp:location>

</metadata>

</resource>

</resources>

</manifest>


<resource> (“sco”)

SCO Meta- data


<file>

<file>

Asset Meta-data


Figure 3.5.2a : Content Aggregation Package


      1. SCORM Content Package Application Profile Requirements

        Table 3.5.3a defines the requirements for each of the aforementioned Content Package Application Profiles. Each of the profiles is listed with the corresponding requirements for each of the content packaging manifest elements/attributes.

        • “M” indicates that the element/attribute is Mandatory.

        • “O” indicates that the element/attribute is Optional.

        • “NP” indicates that the element/attribute is Not Permitted.

        Elements are indicated as they would in the XML Binding (i.e., using XML notation

        <element_name>). Attributes are indicated without any notation (e.g., 1.1 identifier is an attribute of the <manifest> element). The numbering system is based off of the IMS Content Packaging Specification.


        1.5

        <organizations>

        Table 3.5.3a: SCORM Content Package Application Profile Manifest Element Requirements


        No.

        Elements

        Resource Package

        Content Aggregation Package

        1

        <manifest>

        M

        M

        1.1

        identifier

        M

        M

        1.2

        version

        O

        O

        1.3

        xml:base

        O

        O

        1.4

        <metadata>

        O

        O

        1.4.1

        <schema>

        O

        O

        1.4.2

        <schemaversion>

        O

        O

        1.4.3

        {Meta-data}

        O

        O



        M

        M

        1.5.1

        default

        NP

        M

        1.5.2

        <organization>

        NP

        M

        1.5.2.1

        identifier

        NP

        M

        1.5.2.2

        structure

        NP

        O

        1.5.2.3

        adlseq:objectivesGlobalToSystem

        NP

        O

        1.5.2.4

        <title>

        NP

        M

        1.5.2.5

        <item>

        NP

        M

        1.5.2.5.1

        identifier

        NP

        M

        1.5.2.5.2

        identifierref

        NP

        O

        1.5.2.5.3

        <title>

        NP

        M

        1.5.2.5.4

        isvisible

        NP

        O

        1.5.2.5.5

        parameters

        NP

        O

        1.5.2.5.6

        <item>

        NP

        O

        1.5.2.5.7

        <metadata>

        NP

        O

        1.5.2.5.7.1

        {Meta-data}

        NP

        O

        1.5.2.5.8

        <adlcp:timeLimitAction>

        NP

        O

        1.5.2.5.9

        <adlcp:dataFromLMS>

        NP

        O

        1.5.2.5.10

        <adlcp:completionThreshold>

        NP

        O

        1.5.2.5.11

        <imsss:sequencing>

        NP

        O

        1.5.2.5.12

        <adlnav:presentation>

        NP

        O


        1.5.2.6

        <metadata>

        NP

        O

        1.5.2.6.1

        {Meta-data}

        NP

        O

        1.5.2.7

        <imsss:sequencing>

        NP

        O

        1.6

        <resources>

        M

        M

        1.6.1

        xml:base

        O

        O

        1.6.2

        <resource>

        O

        O

        1.6.2.1

        identifier

        M

        M

        1.6.2.2

        type

        M

        M

        1.6.2.3

        href

        O

        O

        1.6.2.4

        adlcp:scormType

        M

        M

        1.6.2.5

        adlcp:persistState

        O

        O

        1.6.2.6

        xml:base

        O

        O

        1.6.2.7

        <metadata>

        O

        O

        1.6.2.7.1

        {Meta-data}

        O

        O

        1.6.2.8

        <file>

        O

        O

        1.6.2.8.1

        href

        M

        M

        1.6.2.8.2

        <metadata>

        O

        O

        1.6.2.8.2.1

        {Meta-data}

        O

        O

        1.6.2.9

        <dependency>

        O

        O

        1.6.2.9.1

        identifierref

        M

        M

        1.7

        <manifest>

        O

        O




        O

        1.8

        <imsss:sequencingCollection>

        NP


    1. Best Practices and Practical Guidelines

      The following section describes a set of recommended best practices and practical guidelines for the development of content packages. These best practices are not considered conformance requirements.


      1. Multiple Organizations for a Single Course

        The content package allows for representations of multiple organizations for its resources. The same resources may be used in different content organizations adapted for different audiences. For example, one may find value in forcing a novice user to progress through content in a linear manner without the ability to skip any instructional units, while an advanced user may want to use the content as a refresher by selecting only the instructional units that they would like to experience. Multiple organizations can be used to structure a set of resources in different ways for different reasons. The utilization of multiple organization elements is ideal for the use case. However, if content developers would like to package and move multiple distinct courses, then those courses should be created in separate (sub)manifests.


      2. Packaging Learning Content for Reuse

        The scope of a manifest is elastic. A manifest can describe a part of a content organization that can exist by itself outside of the context of a course (an instructional object), an entire content organization, or a collection of content organizations. This decision is given to content developers to describe their content in the way they want it to be considered for aggregation or disaggregation.

        The general rule is that a Content Package always contains a single top-level manifest that may contain one or more (sub)manifests. The top-level manifest always describes the Package. Any nested (sub)manifests describe the content at the level to which the (sub)manifest is scoped, such as a course, instructional object or other level.

        For example, if all content comprising a content organization is tightly coupled that no part of it may be presented out of the content organization’s context, a content developer would want to use a single manifest to describe that content organization’s resources and organization. However, content developers who create “instructional objects” that could be recombined with other “instructional objects” to create different course presentations would want to describe each “instructional object” in its own manifest, then aggregate those manifests into a higher-level manifest containing a content organization.

      3. Using the <dependency> Element

Several learning resources, defined in a content package, may contain the same set of files. The files are represented as <file> elements in the manifest. The <dependency> element can be used to group these sets of files. The use of the <dependency> element in this scenario will alleviate the duplication of the <file> element for each set of files in each resource. In this scenario, a <resource> element can be used to gather the set of files. Once the <resource> is set up, all of the other resources that depend on the set of files, can reference the resource by using the <dependency> element.


<manifest>

<organizations>

<organization>

<item identifier="ID1" identifierref="R_ID1"></item>

<item identifier="ID2" identifierref="R_ID2"></item>

</organization>

</organizations>

<resources>

<resource identifier="R_ID1" adlcp:scormType="sco" href="index_1.htm">

<file href="index_1.htm"/>

<file href="image1.jpg"/>

<file href="image2.jpg"/>

<file href="image3.jpg"/>

<file href="apiWrapper.js"/>

</resource>

<resource identifier="R_ID2" adlcp:scormType="sco" href="index_1.htm">

<file href="index.htm"/>

<file href="image1.jpg"/>

<file href="image2.jpg"/>

<file href="image3.jpg"/>

<file href="image4.gif"/>

<file href="apiWrapper.js"/>

</resource>

</resources>

</manifest>

Code Illustration 3-31

In Code Illustration 3-31, the two defined resources both share a common set of files:

These sets of files are repeated, as <file> elements, for each resource. The method described above can be used to eliminate the repeating of these <file> elements.


<manifest>

<organizations>

<organization>

<item identifier="ID1" identifierref="R_ID1"></item>

<item identifier="ID2" identifierref="R_ID2"></item>

</organization>

</organizations>

<resources>

<resource identifier="R_ID1" adlcp:scormType="sco" href="index_1.htm">

<file href="index_1.htm"/>

<dependency identifierref="DEP_R_ID1"/>

</resource>

<resource identifier="R_ID2" adlcp:scormType="sco" href="index_1.htm">

<file href="index.htm"/>

<file href="image4.gif"/>

<dependency identifierref="DEP_R_ID1"/>

</resource>

<resource identifier="DEP_R_ID1" adlcp:scormType="asset">

<file href="image1.jpg"/>

<file href="image2.jpg"/>

<file href="image3.jpg"/>

<file href="apiWrapper.js"/>

</resource>

</resources>

</manifest>

Code Illustration 3-32

In Code Illustration 3-32, a resource was created to hold the commonly used set of files. The resource was given a unique identifier, as required. The newly created resource is an asset. No href attribute was provided by the resource. The asset will never be launched by an LMS (no <item> identifierref references the resource). The resources that share these sets of files now contain a <dependency> element that references, using the identifierref attribute, the newly created resource.


This page intentionally left blank.


SECTION 4

SCORM Meta-data


This page intentionally left blank.


    1. SCORM Meta-Data Overview

      Up to this point, SCORM has described the basic building blocks (SCORM Content Model Components) for content development. SCORM has also described how to bundle the building blocks into Content Aggregations and package those pieces for distribution from system to system. Once the SCORM Content Model Components have been built, it is useful to describe those components in a consistent manner. Describing the components with meta-data facilitates the search and discovery of the components across systems. An LMS could use the meta-data to give the learner information about the content organization (i.e., course, lesson, module, etc). Meta-data can also be used at run-time to help in the decision of what content model component to deliver to the learner.

      This section provides specific requirements and guidance for applying meta-data to SCORM Content Model Components. The SCORM Meta-data Application Profiles defined in this section directly reference the IEEE 1484.12.1-2002 Learning Object Meta- data (LOM) [11] standard and the IEEE 1484.12.3 Draft Standard for Extensible Markup Language (XML) Binding for Learning Object Metadata Data Model [14]. The IEEE provides roughly 64 meta-data elements – more than would be practical for everyday use. This section defines, in the SCORM context, which data elements are mandatory in meta- data used for tagging the components described in the Content Aggregation Model.

      While SCORM fully adheres to the IEEE standard, this section provides additional specific guidance for using meta-data to describe SCORM components. SCORM strongly recommends the use of the IEEE LOM for describing SCORM Content Model Components. However, other meta-data schemes may be used. These meta-data schemes may or may not be recognized by systems.

      The following section is broken up into five basic subsections each describing a different piece to SCORM Meta-data:

      • Section 4.1: Meta-data Overview. This section provides a general overview and background information on LOM.

      • Section 4.2: Meta-data Creation. This section defines requirements for creating meta-data. The section provides the details on the requirements defined by IEEE and how these requirements affect SCORM. This section provides the details on building XML instances adhering to the IEEE LOM requirements.

      • Section 4.3: LOM XML Schema Validation Approaches. This section describes the validation approaches developed by IEEE Draft Standard for Extensible Markup Language (XML) Binding for Learning Object Metadata Data Model. The validation approaches provide different support for XML validation requirements depending on user needs.

      • Section 4.4: Meta-data Extensions. This section describes the extension capabilities defined by IEEE Draft Standard for Extensible Markup Language

        (XML) Binding for Learning Object Metadata Data Model and SCORM. The section also discusses the pros and cons to creating extensions.

        • Section 4.5: SCORM Meta-data Application Profiles. This section provides specific guidance for how to implement meta-data in the SCORM environment. All elements defined by IEEE are considered optional for use. This section defines SCORM mandatory elements for the different SCORM Meta-data Application Profiles and how they are expressed in XML for SCORM conformance.

        The purpose of meta-data is to provide a common nomenclature enabling learning resources to be described in a common way. Meta-data can be collected in catalogs, as well as directly packaged with the learning resource it describes. Learning resources that are described with meta-data can be systematically searched for and retrieved for use and reuse.

        SCORM applies the IEEE LOM meta-data element definitions to SCORM Content Model Components described in the Content Aggregation Model. These components define the meta-data aspects of the SCORM CAM.

        This mapping of standardized definitions from IEEE to the SCORM CAM provides the missing link between general specifications and specific content models. The following sections define the SCORM application of the IEEE standards to the meta-data aspects of the SCORM CAM.


    2. SCORM Meta-data Creation

The following sections outline the LOM XML meta-data elements. According to the IEEE, every LOM meta-data element is optional. This implies that when building a XML meta-data instance, the developer can optionally pick and choose which elements to use.

In order to meet several of the key high-level requirements of ADL, SCORM places additional requirements on which elements are mandatory in SCORM-conformant meta- data XML instances. These additional requirements enable the ability to describe those objects with meta-data (in a consistent manner using a consistent set of required elements) and the ability to find those learning objects in a repository so they can be used in other contexts. This list of required elements is different depending on the SCORM Content Model Component (Asset, SCO, Activity, Content Organization, Content Aggregation) being described by the meta-data. Refer to Section 4.5.2: SCORM Meta- data Application Profile Requirements for a complete listing of the elements and their usage requirements.

The 1484.12.1-2002 Information Model (hereafter referred to as LOM Information Model) describes the set of data elements that are available to build SCORM-conformant meta-data. Along with the requirements defined in the LOM Information Model, SCORM defines Application Profiles for several types of meta-data instances. These requirements and definitions of the application profiles can be found in Section 4.5.2: SCORM Meta-data Application Profile Requirements. SCORM-conformant meta-data may contain additional data elements, as described in Section 4.4: Meta-data Extensions.

The LOM Information Model is broken up into nine categories. These categories are based on the definitions found in the LOM Information Model. The nine categories of meta-data elements are:

  1. The General category can be used to describe general information about the SCORM Content Model Component as a whole.

  2. The Life Cycle category can be used to describe features related to the history and current state of the SCORM Content Model Component and those who have affected the component during its evolution.

  3. The Meta-metadata category can be used to describe information about the meta- data record itself (rather than the SCORM Content Model Component that the record describes).

  4. The Technical category can be used to describe technical requirements and characteristics of the SCORM Content Model Components.

  5. The Educational category can be used to describe the educational and pedagogic characteristics of the SCORM Content Model Component.

  6. The Rights category can be used to describe the intellectual property rights and conditions of use for the SCORM Content Model Component.

  7. The Relation category can be used to describe features that define the relationship between this SCORM Content Model Component and other targeted components.

  8. The Annotation category can be used to provide comments on the educational use of the SCORM Content Model Component and information on when and by whom the comments were created.

  9. The Classification category can be used to describe where the SCORM Content Model Component falls within a particular classification system.

Some elements use the term smallest permitted maximum (SPM) in describing the multiplicity and/or data types. The SPM indicates that applications that process meta- data shall process at least that number of elements or number of characters, but are free to support and exceed the limit.

For those elements that have a data type of a Vocabulary Type, additional information is provided on whether or not the vocabulary is a Restricted or Best Practice Vocabulary. Restricted indicates that the meta-data element is restricted to the vocabulary entries listed. Best Practice indicates that SCORM recommends using the listed vocabulary entries as the “best practice” for doing so.

The following table is used to describe the SCORM Meta-data Application Profile (refer to Section 4.5 for more details) requirements:


Table 3.4.1a: SCORM Meta-data Application Profile Table Format


SCORM Meta-data Application Profile

Meta-data Multiplicity Requirements

Content Aggregation

<requirement> (SPM: x)

Content Organization

<requirement> (SPM: x)

Activity

<requirement> (SPM: x)

SCO

<requirement> (SPM: x)

Asset

<requirement> (SPM: x)


The left-hand column is title SCORM Meta-data Application Profile. This column describes the types of application profiles defined by SCORM. The right-hand column is title Meta-data Multiplicity Requirements. This column defines the multiplicity requirement for the XML elements in the meta-data.


Table 3.4.1b: Explanation of Multiplicity Requirements


Multiplicity Requirement

Explanation

1 and only 1

The element must exist 1 and only 1 time within the parent element

0 or More

The element can exist 0 or More times within the parent element.

1 or More

The element must exist 1 or More times within the parent

element.

2 or More

The element must exist 2 or More times within the parent element.

0 or 1

The element can exist 0 or 1 time within the parent element.

Table 3.4.1b defines the types of multiplicities that are used in this section. Each type is accompanied by a brief explanation. The table also has definitions for smallest permitted maximums (SPMs) for those elements that have a multiplicity of more than 1. The SPM indicates the smallest number of elements that must be supported by a processing system.


      1. <lom> Element

        All meta-data instances shall have <lom> as the root node. The root node begins to define the meta-data used to describe the SCORM Content Model Component. When placed in a content package (refer to Section 4.5.1: Associating Meta-data with SCORM Components), all meta-data is placed within a <imscp:metadata> element (refer to Section 3.4.1: Manifest File) found in an imsmanifest.xml file. The <lom> root node encapsulates all of the categories described above. There is no implied order of the nine categories. The child elements can appear in any order.

        All namespace declarations should be declared inside the <lom> element. This includes any namespaces that are considered extensions to the meta-data. Although this is not considered a requirement, based on the XML specifications, ADL considers this to be a “best practice” and urges vendors and tools to provide this information.

        XML Namespace: http://ltsc.ieee.org/xsd/LOM

        XML Namespace Prefix: lom

        XML Binding Representation: <lom>

        SCORM Requirements: The <lom> element contains important elements that SCORM requires to describe all of the SCORM Content Model Components.


        SCORM Meta-data Application Profile

        Meta-data Multiplicity Requirements

        Content Aggregation

        1 and only 1

        Content Organization

        1 and only 1

        Activity

        1 and only 1

        SCO

        1 and only 1

        Asset

        1 and only 1

        Data Type: The <lom> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The <lom> element contains the following child elements:

        • <general>

        • <lifeCycle>

        • <metaMetadata>

        • <technical>

        • <educational>

        • <rights>

        • <relation>

        • <annotation>

        • <classification>

        The example is used to illustrate the concepts described above. The nine category elements are represented as empty elements for simplicity.


        <lom xmlns="http://ltsc.ieee.org/xsd/LOM">

        <general/>

        <classification/>

        <annotation/>

        <lifeCycle/>

        <technical/>

        <metaMetadata/>

        <educational/>

        <relation/>

        <rights/>

        </lom>

Code Illustration 4-1


      1. <general> Element

        The General category groups the general information that describes the resource as a whole. The resource in this case is the particular SCORM Content Model Component (Asset, SCO, Activity or Content Organization) being described. This general information is sometimes viewed as key information in that it is important for describing the particular component.

        XML Namespace: http://ltsc.ieee.org/xsd/LOM

        XML Namespace Prefix: lom

        XML Binding Representation: <general>

        SCORM Requirements: The multiplicity requirements for the <general> element are defined in the table below:


        SCORM Meta-data Application Profile

        Meta-data Multiplicity Requirements

        Content Aggregation

        0 or 1

        Content Organization

        1 and only 1

        Activity

        1 and only 1

        SCO

        1 and only 1

        Asset

        1 and only 1

        Data Type: The <general> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

        <general> element contains the following child elements:

        • <identifier>

        • <title>

        • <language>

        • <description>

        • <keyword>

        • <coverage>

        • <structure>

        • <aggregationLevel>


          <lom>

          <general>

          <identifier>

          <catalog>URI</catalog>

          <entry>http://www.adlnet.org/content/CO_01</entry>

          </identifier>

          <title>

          <string language="en">Title for the learning object</string>

          </title>

          <language>en</language>

          <description>

          <string language="en">Textual description</string>

          </description>

          <keyword>

          <string language="en">learning object</string>

          </keyword>

          <coverage>

          <string language="en">Circa, 16th century France</string>

          </coverage>

          <structure>

          <source>LOMv1.0</source>

          <value>atomic</value>

          </structure>

          <aggregationLevel>

          <source>LOMv1.0</source>

          <value>2</value>

          </aggregationLevel>

          </general>

          </lom>

Code Illustration 4-2


        1. <identifier> Element

          The <identifier> element represents a mechanism for assigning a globally unique label that identifies the SCORM Content Model Component. The notion of assigning a globally unique identifier to a component is important when dealing with multiple facets of learning content development (e.g., versioning, maintenance, etc.).

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <identifier>

          SCORM Requirements: The multiplicity requirements for the <identifier> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 10)

          Content Organization

          1 or More (SPM 10)

          Activity

          1 or More (SPM 10)

          SCO

          1 or More (SPM 10)

          Asset

          1 or More (SPM 10)

          Data Type: The <identifier> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

          <identifier> element contains the following child elements:

          • <catalog> - optional

          • <entry> - mandatory

          Example:


          <lom>

          <general>

          <identifier>

          <catalog>URI</catalog>

          <entry>http://www.adlnet.org/content/CO_01</entry>

          </identifier>

          </general>

          </lom>

Code Illustration 4-3

          1. <catalog> Element

            The <catalog> element represents the name or designator of the identification or cataloging scheme for the entry. There are a variety of cataloging systems available. SCORM does not require the use of any one particular cataloging system. Organizations are free to choose any cataloging scheme that meets their organizations practices or policies. Some types of Cataloging systems are:

            • Universal Resource Identifier (URI)

            • Universal Resource Name (URN)

            • Digital Object Identifier (DOI)

            • International Standard Book Numbers (ISBN)

            • International Standard Serial Numbers (ISSN)

              The <catalog> element represents the scheme used to create and manage the entry.

              XML Namespace: http://ltsc.ieee.org/xsd/LOM

              XML Namespace Prefix: lom

              XML Binding Representation: <catalog>

              SCORM Requirements: The multiplicity requirements for the <catalog> element are defined in the table below:


              SCORM Meta-data Application Profile

              Meta-data Multiplicity Requirements

              Content Aggregation

              0 or 1

              Content Organization

              0 or 1

              Activity

              0 or 1

              SCO

              0 or 1

              Asset

              0 or 1

              SCORM recommends the use of the <catalog> element to describe the catalog or identification system for the <entry> element.

              Data Type: The <catalog> element is represented as a CharacterString element. The CharacterString has an SPM of 1000 characters (Refer to Section 4.2.11.1: CharacterString Data Type for more information).

              Example:


              <lom>

              <general>

              <identifier>

              <catalog>URI</catalog>

              <entry>http://www.adlnet.org/content/CO_01</entry>

              </identifier>

              </general>

              </lom>

Code Illustration 4-4

          1. <entry> Element

The <entry> element represents the value of the identifier within the identification or cataloging scheme (see <catalog> element) that designates or identifies the learning object.

Identifiers can take on various formats. The IEEE requires that the actual identifier value be represented as a CharacterString. Organizations are free to choose any mechanism to create unique identifiers that meets their organizations practices or policies.

The following listing is a sampling of identifier values (entry):


Scheme (<catalog>)

Value (<entry>)

Universal Resource Name

urn:ADL: 1345-GFGC-23ED-3321

Universal Resource Identifier

http://www.adlnet.org/content/C0_01

ADL Registry

2134-RF43-3233-FRI9-ACDA


ADL Note: ADL Registry does not exist. This is just an example of one type of registry system that may exist.

XML Namespace: http://ltsc.ieee.org/xsd/LOM

XML Namespace Prefix: lom

XML Binding Representation: <entry>

SCORM Requirements: The multiplicity requirements for the <entry> element are defined in the table below:


SCORM Meta-data Application Profile

Meta-data Multiplicity Requirements

Content Aggregation

0 or 1

Content Organization

1 and only 1

Activity

1 and only 1

SCO

1 and only 1

Asset

1 and only 1

SCORM places a requirement that the <entry> element shall be present. The actual value used to identify the learning resource is held by the <entry> element.

Data Type: The <entry> element’s value is represented as a CharacterString. The CharacterString has an SPM of 1000 characters (Refer to Section 4.2.11.1: CharacterString Data Type for more information).

Example:


<lom>

<general>

<identifier>

<catalog>URI</catalog>

<entry>http://www.adlnet.org/content/CO_01</entry>

</identifier>

</general>

</lom>

Code Illustration 4-5


        1. <title> Element

          The <title> element represents the name given to the learning object.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <title>

          SCORM Requirements: The multiplicity requirements for the <title> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or 1

          Content Organization

          1 and only 1

          Activity

          1 and only 1

          SCO

          1 and only 1


          Asset

          1 and only 1

          Data Type: The <title> element is represented as a LangString element. The LangString has an SPM of 1000 characters (Refer to Section 4.2.11.2: LangString Data Type for more information).

          Example:


          <lom>

          <general>

          <title>

          <string language="en">Sharable Content Object Reference Model</string>

          </title>

          </general>

          </lom>

Code Illustration 4-6


        1. <language> Element

          The <language> element represents the primary human language or languages used within the SCORM Content Model Component to communicate to the intended user. The Language element can be repeated. This allows for the ability to described components that are built to support multiple languages.

          The value held by the <language> element shall be represented according to the following:

          Language = Langcode(“-“Subcode)*

          Langcode – Represents a language code as defined by ISO 639:1988. This value is mandatory.

          Subcode – Represents a country code from the code set defined by ISO 3166-1997. This value can be repeated and is optional.

          Examples:

          • “en”

          • “en-GB”

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <language>

          SCORM Requirements: The multiplicity requirements for the <language> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 10)

          Content Organization

          0 or More (SPM 10)

          Activity

          0 or More (SPM 10)


          SCO

          Asset

          0 or More (SPM 10)

          0 or More (SPM 10)

          Data Type: The <language> element is represented as a CharacterString element. The CharacterString has an SPM of 100 characters (Refer to Section 4.2.11.1: CharacterString Data Type for more information).

          Example:


          <lom>

          <general>


          <language>en</language>

          <language>fr</language>


          </general>


          </lom>


          Code Illustration 4-7


        2. <description> Element

          The <description> element represents a textual description of the SCORM Content Model Component being described by the meta-data. The Description element allows for a narrative description of the component.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <description>

          SCORM Requirements: The multiplicity requirements for the <description> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 10)

          Content Organization

          1 or More (SPM 10)

          Activity

          1 or More (SPM 10)

          SCO

          1 or More (SPM 10)

          Asset

          1 or More (SPM 10)

          Data Type: The <description> element is represented as a LangString element. The LangString has an SPM of 2000 characters (Refer to Section 4.2.11.2: LangString Data Type for more information).

          Example:


          <lom>

          <general>

          <description>

          <string language="en">Textual description of the learning object</string>

          </description>

          </general>

          </lom>

Code Illustration 4-8


        1. <keyword> Element

          The <keyword> element shall be used to define common keywords or phrases that describe the learning object. When creating keyword(s) the creator should pick words or phrases that are very succinct and specific to the SCORM component. The Keyword element consists of one word or phrase. If more than one Keyword is desired, the creator should use multiple instances of the Keyword element.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <keyword>

          SCORM Requirements: The multiplicity requirements for the <keyword> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 10)

          Content Organization

          1 or More (SPM 10)

          Activity

          1 or More (SPM 10)

          SCO

          1 or More (SPM 10)

          Asset

          0 or More (SPM 10)

          Data Type: The <keyword> element is represented as a LangString element. The LangString has an SPM of 1000 characters (Refer to Section 4.2.11.2: LangString Data Type for more information).

          Example:


          <lom>

          <general>

          <keyword>

          <string language="en">learning object</string>

          <string language="nl">leerobject</string>

          <string language="fr">objet d’apprentissage</string>

          </keyword>

          <keyword>

          <string language="en">metadata</string>

          <string language="nl">metadata</string>

          <string language="fr">métadonnées</string>

          </keyword>

          </general>

          </lom>

Code Illustration 4-9


        1. <coverage> Element

          The <coverage> element shall be used to describe the time, culture, geography or region to which the SCORM Content Model Component applies.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <coverage>

          SCORM Requirements: The multiplicity requirements for the <coverage> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 10)

          Content Organization

          0 or More (SPM 10)

          Activity

          0 or More (SPM 10)

          SCO

          0 or More (SPM 10)

          Asset

          0 or More (SPM 10)

          Data Type: The <coverage> element is represented as a LangString element. The LangString has an SPM of 1000 characters (Refer to Section 4.2.11.2: LangString Data Type for more information).

          Example:


          <lom>

          <general>

          <coverage>

          <string language="en">Circa, 16th century France</string>

          </coverage>

          </general>

          </lom>

Code Illustration 4-10

        1. <structure> Element

          The <structure> element shall describe the underlying organizational structure of the SCORM Content Model Component.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <structure>

          SCORM Requirements: The multiplicity requirements for the <structure> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or 1

          Content Organization

          0 or 1

          Activity

          0 or 1

          SCO

          0 or 1

          Asset

          0 or 1

          Data Type: The <structure> element is represented as a Vocabulary element (Refer to Section 4.2.11.3: Vocabulary Data Type for more information).

          Vocabulary Tokens: SCORM defines the <structure> element as a Restricted Vocabulary element. SCORM requires the use of the vocabulary defined by IEEE 1484.12.1-2002. The valid set of tokens defined by IEEE is:

          • atomic: an object that is indivisible

          • collection: a set of objects with no specified relationship between them

          • networked: a set of objects with relationships that are unspecified

          • hierarchical: a set of objects whose relationships can be represented by a tree structure

          • linear: a set of objects that are fully ordered. Example: A set of objects that are connected by “previous” and “next” relationships.

            Example:


            <lom>

            <general>

            <structure>

            <source>LOMv1.0</source>

            <value>atomic</value>

            </structure>

            </general>

            </lom>

Code Illustration 4-11

        1. <aggregationLevel> Element

          The <aggregationLevel> element shall describe the functional granularity of the learning object.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <aggregationLevel>

          SCORM Requirements: The multiplicity requirements for the <aggregationLevel>

          element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or 1

          Content Organization

          0 or 1

          Activity

          0 or 1

          SCO

          0 or 1

          Asset

          0 or 1

          Data Type: The <aggregationLevel> element is represented as a Vocabulary element (Refer to Section 4.2.11.3: Vocabulary Data Type for more information).

          Vocabulary Tokens: SCORM defines the <aggregationLevel> element as a Restricted Vocabulary element. SCORM requires the use of the vocabulary defined by IEEE 1484.12.1-2002. The valid set of tokens defined by IEEE is:

          • 1: the smallest level of aggregation, e.g., raw media data or fragments.

          • 2: a collection of level 1 learning objects, e.g., a lesson.

          • 3: a collection of level 2 learning objects, e.g., a course

          • 4: the largest level of granularity, e.g., a set of courses that lead to a certificate

            Example:


            <lom>

            <general>

            <aggregationLevel>

            <source>LOMv1.0</source>

            <value>2</value>

            </aggregationLevel>

            </general>

            </lom>

Code Illustration 4-12


      1. <lifeCycle> Element

The Life Cycle category groups the features related to the history and current state of the SCORM Content Model Component and those who have affected the component during its evolution. The typical types of information collected in this category include the status of the component (e.g., is the component in its final state or is it still in a draft format), a version identifier indicating the version of the component and a list of individuals/organizations that have affected the component in one manner or another.

XML Namespace: http://ltsc.ieee.org/xsd/LOM

XML Namespace Prefix: lom

XML Binding Representation: <lifeCycle>

SCORM Requirements: The multiplicity requirements for the <lifeCycle> element are defined in the table below:


SCORM Meta-data Application Profile

Meta-data Multiplicity Requirements

Content Aggregation

0 or 1

Content Organization

1 and only 1

Activity

1 and only 1

SCO

1 and only 1

Asset

0 or 1

Data Type: The <lifeCycle> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

<lifeCycle> element contains the following child elements:


<lom>

<lifeCycle>

<version>

<string language="en">1.0 alpha</string>

</version>

<status>

<source>LOMv1.0</source>

<value>final</value>

</status>

<contribute>

<role>

<source>LOMv1.0</source>

<value>author</value>

</role>

<entity>BEGIN:VCARD\nFN:Joe FridayEND:VCARD</entity>

<date>

<dateTime>2002-12-12</dateTime>

<description>

<string language="en">A description for the date</string>

</description>

</date>

</contribute>

</lifeCycle>

</lom>

Code Illustration 4-13


        1. <version> Element

          The <version> element shall describe the edition of the SCORM Content Model Component. A component may have several versions or editions during its lifetime. The

          <version> element allows for the description of the version of the component.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <version>

          SCORM Requirements: The multiplicity requirements for the <version> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or 1

          Content Organization

          1 and only 1

          Activity

          1 and only 1

          SCO

          1 and only 1

          Asset

          0 or 1

          Data Type: The <version> element is represented as a LangString element. The LangString has an SPM of 50 characters (Refer to Section 4.2.11.2: LangString Data Type for more information).


          <lom>

          <lifeCycle>

          <version>

          <string language="en">1.0 alpha</string>

          </version>

          </lifeCycle>

          </lom>

Code Illustration 4-14


        1. <status> Element

          The <status> element shall describe the completion status or condition of the SCORM Content Model Component. A component may have several statuses during its lifetime (draft, final, etc…). The <status> element allows for the description of the status of the component.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <status>

          SCORM Requirements: The multiplicity requirements for the <status> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or 1

          Content Organization

          1 and only 1

          Activity

          1 and only 1

          SCO

          1 and only 1

          Asset

          0 or 1

          Data Type: The <status> element is represented as a Vocabulary element (Refer to Section 4.2.11.3: Vocabulary Data Type for more information).

          Vocabulary Tokens: SCORM defines the <status> element as a Restricted Vocabulary element. SCORM requires the use of the vocabulary defined by IEEE 1484.12.1-2002.

          The valid set of tokens defined by IEEE is:

          • draft: the component is in a draft state (as determined by the developer)

          • final: the component is in a final state (as determined by the developer)

          • revised: the component has been revised since the last version

          • unavailable: the status information is unavailable


          <lom>

          <lifeCycle>

          <status>

          <source>LOMv1.0</source>

          <value>final</value>

          </status>

          </lifeCycle>

          </lom>

Code Illustration 4-15


        1. <contribute> Element

          The <contribute> element shall be used to describe those entities (i.e., people, organizations) that have contributed to the state of the SCORM Content Model Component during its lifecycle (e.g., creation, edits, reviews, publications, etc). The Contribute element enables capturing of all those individuals or organizations involved.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <contribute>

          SCORM Requirements: The multiplicity requirements for the <contribute> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 30)

          Content Organization

          0 or More (SPM 30)

          Activity

          0 or More (SPM 30)

          SCO

          0 or More (SPM 30)

          Asset

          0 or More (SPM 30)

          If the <contribute> element is used, SCORM requires the use of the <role> and

          <entity> element. These elements describe what role and what entity was involved with the contribution.

          Data Type: The <contribute> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

          <contribute> element contains the following child elements:

          • <role> - mandatory if a <contribute> element is used

          • <entity> - mandatory if a <contribute> element is used

          • <date> - optional if a <contribute> element is used


            <lom>

            <lifeCycle>

            <contribute>

            <role>

            <source>LOMv1.0</source>

            <value>author</value>

            </role>

            <entity>BEGIN:VCARD\nFN:Joe FridayEND:VCARD</entity>

            <date>

            <dateTime>2002-12-12</dateTime>

            <description>

            <string language="en">A description for the date</string>

            </description>

            </date>

            </contribute>

            </lifeCycle>

            </lom>


          1. <role> Element

            Code Illustration 4-16

            The <role> element defines the kind or type of contribution made by the contributor (identified by the Entity element). The IEEE has defined a set of typical roles that are involved with the lifecycle of the component.

            XML Namespace: http://ltsc.ieee.org/xsd/LOM

            XML Namespace Prefix: lom

            XML Binding Representation: <role>

            SCORM Requirements: The multiplicity requirements for the <role> element are defined in the table below:


            SCORM Meta-data Application Profile

            Meta-data Multiplicity Requirements

            Content Aggregation

            0 or 1

            Content Organization

            0 or 1

            Activity

            0 or 1

            SCO

            0 or 1

            Asset

            0 or 1

            If the <contribute> element is used, SCORM requires the use of the <role> element. The <role> element describes the role the contributor played in the development of the SCORM Content Model Component.

            Data Type: The <role> element is represented as a Vocabulary element (Refer to Section 4.2.11.3: Vocabulary Data Type for more information).

            Vocabulary Tokens: SCORM defines the <role> element as a Best Practice Vocabulary element. SCORM does not require the use of the vocabulary defined by

            IEEE 1484.12.1-2002. SCORM, however, does recommend the use of the values as best practice. The valid set of tokens defined by IEEE is:

            • author

            • publisher

            • unknown

            • initiator

            • terminator

            • validator

            • editor

            • graphical designer

            • technical implementer

            • content provider

            • technical validator

            • educational validator

            • script writer

            • instructional designer

            • subject matter expert

              Example:


              <lom>

              <lifeCycle>

              <contribute>

              <role>

              <source>LOMv1.0</source>

              <value>author</value>

              </role>

              </contribute>

              </lifeCycle>

              </lom>

Code Illustration 4-17

          1. <entity> Element

            The <entity> element identifies the entity or entities that may have contributed during the development lifecycle of the SCORM Content Model Component. An entity can be an individual person, organization, etc. If more than one entity is listed, the entities shall be ordered as most relevant first.

            XML Namespace: http://ltsc.ieee.org/xsd/LOM

            XML Namespace Prefix: lom

            XML Binding Representation: <entity>

            SCORM Requirements: The multiplicity requirements for the <entity> element are defined in the table below:


            SCORM Meta-data Application Profile

            Meta-data Multiplicity Requirements

            Content Aggregation

            0 or More (SPM 40)

            Content Organization

            0 or More (SPM 40)

            Activity

            0 or More (SPM 40)

            SCO

            0 or More (SPM 40)

            Asset

            0 or More (SPM 40)

            If the <contribute> element is used, SCORM requires the use of the <entity> element. The <entity> element describes who was involved with the development of the SCORM Content Model Component.

            Data Type: The <entity> element is a CharacterString element. The CharacterString has an SPM of 1000 characters. (Refer to Section 4.2.11.1: CharacterString Data Type for more information). All entity values shall be represented in vCard [9] format. This allows systems to take the CharacterString represented by the <entity> element and process this CharacterString as a valid vCard.

            Example:


            <lom>

            <lifeCycle>

            <contribute>

            <role>

            <source>LOMv1.0</source>

            <value>author</value>

            </role>

            <entity>BEGIN:VCARD\nFN:Joe AuthorEND:VCARD</entity>

            <entity>BEGIN:VCARD\nFN:Mary AuthorEND:VCARD</entity>

            <date>

            <dateTime>2002-12-12</dateTime>

            <description>

            <string language="en">A description for the date</string>

            </description>

            </date>

            </contribute>

            </lifeCycle>

            </lom>

Code Illustration 4-18

          1. <date> Element

The <date> element identifies the date of the contribution made by the entity.

XML Namespace: http://ltsc.ieee.org/xsd/LOM

XML Namespace Prefix: lom

XML Binding Representation: <date>

SCORM Requirements: The multiplicity requirements for the <date> element are defined in the table below:


SCORM Meta-data Application Profile

Meta-data Multiplicity Requirements

Content Aggregation

0 or 1

Content Organization

0 or 1

Activity

0 or 1

SCO

0 or 1

Asset

0 or 1

Data Type: The Date element is represented as a DateTime data type (Refer to Section 4.2.11.4: DateTime Data Type for more information). The <date> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The <date> element contains two elements, one that represents the actual date of the contribution (<dateTime>) and one that represents a textual description of the date (<description>):

Example:


<lom>

<lifeCycle>

<contribute>

<role>

<source>LOMv1.0</source>

<value>author</value>

</role>

<entity>BEGIN:VCARD\nFN:Joe AuthorEND:VCARD</entity>

<entity>BEGIN:VCARD\nFN:Mary AuthorEND:VCARD</entity>

<date>

<dateTime>2002-12-12</dateTime>

<description>

<string language="en">This date represents the date the author finished authoring the component.</string>

</description>

</date>

</contribute>

</lifeCycle>

</lom>

Code Illustration 4-19


      1. <metaMetadata> Element

        The Meta-Metadata category provides elements that describe the meta-data record itself and not the SCORM Content Model Component the record is describing. This category describes how the meta-data instance itself can be identified, who created the meta-data instance, how, when and with what references.

        XML Namespace: http://ltsc.ieee.org/xsd/LOM

        XML Namespace Prefix: lom

        XML Binding Representation: <metaMetadata>

        SCORM Requirements: The multiplicity requirements for the <metaMetadata>

        element are defined in the table below:


        SCORM Meta-data Application Profile

        Meta-data Multiplicity Requirements

        Content Aggregation

        1 and only 1

        Content Organization

        1 and only 1

        Activity

        1 and only 1

        SCO

        1 and only 1

        Asset

        1 and only 1

        Data Type: The <metaMetadata> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

        <metaMetadata> element contains the following child elements:

        • <identifier>

        • <contribute>

        • <metadataSchema>

        • <language>

        Example:


        <lom>

        <metaMetadata>

        <identifier>

        <catalog>URI</catalog>

        <entry>http://www.adlnet.org/metadata/MDO_01</entry>

        </identifier>

        <contribute>

        <role>

        <source>LOMv1.0</source>

        <value>creator</value>

        </role>

        <entity>BEGIN:VCARD\nFN:Joe Metadata CreatorEND:VCARD</entity>

        <date>

        <dateTime>2002-12-12</dateTime>

        <description>

        <string language="en">This date represents the date the creator finished authoring the metadata.</string>

        </description>

        </date>

        </contribute>

        <metadataSchema>LOMv1.0</metadataSchema>

        <metadataSchema>SCORM_CAM_v1.3</metadataSchema>

        <language>en</language>

        </metaMetadata>

        </lom>

Code Illustration 4-20


        1. <identifier> Element

          The <identifier> element represents a mechanism for assigning a globally unique label that identifies the meta-data record that describes the SCORM Content Model Component.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <identifier>

          SCORM Requirements: The multiplicity requirements for the <identifier> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 10)

          Content Organization

          1 or More (SPM 10)

          Activity

          1 or More (SPM 10)

          SCO

          1 or More (SPM 10)

          Asset

          1 or More (SPM 10)

          Data Type: The <identifier> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

          <identifier> element contains the following child elements:

          • <catalog> - optional

          • <entry> - mandatory

          Example:


          <lom>

          <metaMetadata>

          <identifier>

          <catalog>URI</catalog>

          <entry>http://www.adlnet.org/metadata/MDO_01</entry>

          </identifier>

          </metaMetadata>

          </lom>

Code Illustration 4-21

          1. <catalog> Element

            The <catalog> element represents the name or designator of the identification or cataloging scheme for the entry. There are a variety of cataloging systems available. SCORM does not require the use of any one particular cataloging system. Organizations are free to choose any cataloging scheme that meets their organizations practices or policies. Some types of Cataloging systems are:

            • Universal Resource Identifier (URI)

            • Universal Resource Name (URN)

            • Digital Object Identifier (DOI)

            • International Standard Book Numbers (ISBN)

            • International Standard Serial Numbers (ISSN)

              The <catalog> element represents the scheme used to create and manage the entry.

              XML Namespace: http://ltsc.ieee.org/xsd/LOM

              XML Namespace Prefix: lom

              XML Binding Representation: <catalog>

              SCORM Requirements: The multiplicity requirements for the <catalog> element are defined in the table below:


              SCORM Meta-data Application Profile

              Meta-data Multiplicity Requirements

              Content Aggregation

              0 or 1

              Content Organization

              0 or 1

              Activity

              0 or 1

              SCO

              0 or 1

              Asset

              0 or 1

              SCORM recommends the use of the <catalog> element to describe the catalog or identification system for the <entry> element.

              Data Type: The <catalog> element is represented as a CharacterString element. The CharacterString has an SPM of 1000 characters (Refer to Section 4.2.11.1: CharacterString Data Type for more information).

              Example:


              <lom>

              <metaMetadata>

              <identifier>

              <catalog>URI</catalog>

              <entry>http://www.adlnet.org/metadata/MDO_01</entry>

              </identifier>

              </metaMetadata>

              </lom>

Code Illustration 4-22

          1. <entry> Element

            The <entry> element represents the value of the identifier within the identification or cataloging scheme (see <catalog> element) that designates or identifies the meta-data.

            Identifiers can take on various formats. The IEEE requires that the actual identifier value be represented as a CharacterString. Organizations are free to choose any mechanism to create unique identifiers that meets their organizations practices or policies. It is recommended that a common scheme be chosen.

            The following listing is a sampling of identifier values (entry):


            Scheme (<catalog>)

            Value (<entry>)

            Universal Resource Name

            urn:ADL: 1345-GFGC-23ED-3321

            Universal Resource Identifier

            http://www.adlnet.org/content/C0_01

            ADL Registry

            2134-RF43-3233-FRI9-ACDA


            ADL Note: ADL Registry does not exist. This is just an example of one type of registry system that may exist .

            XML Namespace: http://ltsc.ieee.org/xsd/LOM

            XML Namespace Prefix: lom

            XML Binding Representation: <entry>

            SCORM Requirements: The multiplicity requirements for the <entry> element are defined in the table below:


            SCORM Meta-data Application Profile

            Meta-data Multiplicity Requirements

            Content Aggregation

            0 or 1

            Content Organization

            1 and only 1

            Activity

            1 and only 1

            SCO

            1 and only 1


            Asset

            1 and only 1

            SCORM places a requirement that the <entry> element shall be present. The actual value used to identify the meta-data describing the learning resource.

            Data Type: The <entry> element is represented as a CharacterString element. The CharacterString has an SPM of 1000 characters (Refer to Section 4.2.11.1: CharacterString Data Type for more information).

            Example:


            <lom>

            <metaMetadata>

            <identifier>

            <catalog>URI</catalog>

            <entry>http://www.adlnet.org/metadata/MDO_01</entry>

            </identifier>

            </metaMetadata>

            </lom>

Code Illustration 4-23


        1. <contribute> Element

          The <contribute> element shall be used to describe those entities (i.e., people, organizations) that have affected the state of the meta-data (not the SCORM Content Model Component being described) instance during its development lifecycle. The

          <contribute> element enables capturing of all those individuals or organizations involved.

          XML Namespace: http://ltsc.ieee.org/xsd/LOM

          XML Namespace Prefix: lom

          XML Binding Representation: <contribute>

          SCORM Requirements: The multiplicity requirements for the <contribute> element are defined in the table below:


          SCORM Meta-data Application Profile

          Meta-data Multiplicity Requirements

          Content Aggregation

          0 or More (SPM 30)

          Content Organization

          0 or More (SPM 30)

          Activity

          0 or More (SPM 30)

          SCO

          0 or More (SPM 30)

          Asset

          0 or More (SPM 30)

          If the <contribute> element is used, SCORM requires the use of the <role> and

          <entity> element. These elements describe what role and what entity was involved with the contribution.

          Data Type: The <contribute> element is a parent element. Parent elements have no values associated with them. Parent elements act as “containers” for other elements. The

          <contribute> element contains the following child elements:

          • <role> - mandatory if a <contribute> element is used

          • <entity> - mandatory if a <contribute> element is used

          • <date> - optional if a <contribute> element is used

          Example:


          <lom>

          <metaMetadata>

          <contribute>

          <role>

          <source>LOMv1.0</source>

          <value>creator</value>

          </role>

          <entity>BEGIN:VCARD\nFN:Joe Metadata CreatorEND:VCARD</entity>

          <date>

          <dateTime>2002-12-12</dateTime>

          <description>

          <string language="en">This date represents the date the creator finished authoring the metadata.</string>

          </description>

          </date>

          </contribute>

          </metaMetadata>

          </lom>


          1. <role> Element

            Code Illustration 4-24

            The <role> element defines the kind or type of contribution made by the contributor (identified by the Entity element). The IEEE has defined a set of typical roles that are involved with the development lifecycle of the meta-data instance.

            XML Namespace: http://ltsc.ieee.org/xsd/LOM

            XML Namespace Prefix: lom

            XML Binding Representation: <role>

            SCORM Requirements: The multiplicity requirements for the <role> element are defined in the table below:


            SCORM Meta-data Application Profile

            Meta-data Multiplicity Requirements

            Content Aggregation

            0 or 1

            Content Organization

            0 or 1

            Activity

            0 or 1

            SCO

            0 or 1

            Asset

            0 or 1

            If the <contribute> element is used, SCORM requires the use of the <entity> element. The <entity> element describes who was involved with the development of the SCORM Content Model Component.

            Data Type: The <role> element is represented as a Vocabulary element (Refer to Section 4.2.11.3: Vocabulary Data Type for more information).

            Vocabulary Tokens: SCORM defines the <role> element as a Best Practice Vocabulary element. SCORM does not require the use of the vocabulary defined by IEEE 1484.12.1-2002. SCORM, however, does recommend the use of the values as best practice. The valid set of tokens defined by IEEE is:

            • creator

            • validator

              Example:


              <lom>

              <metaMetadata>

              <contribute>

              <role>

              <source>LOMv1.0</source>

              <value>creator</value>

              </role>

              <entity>BEGIN:VCARD\nFN:Joe Metadata CreatorEND:VCARD</entity>

              <date>

              <dateTime>2002-12-12</dateTime>

              <description>

              <string language="en">This date represents the date the creator finished authoring the metadata.</string>

              </description>

              </date>

              </contribute>

              </metaMetadata>

              </lom>

Code Illustration 4-25

          1. <entity> Element

            The <entity> element identifies the entity or entities that may have contributed during the development lifecycle of the meta-data instance. An entity can be an individual person, organization, etc. If more than one entity is listed, the entities shall be ordered as most relevant first.

            XML Namespace: http://ltsc.ieee.org/xsd/LOM

            XML Namespace Prefix: lom

            XML Binding Representation: <entity>

            SCORM Requirements: The multiplicity requirements for the <entity> element are defined in the table below:


            SCORM Meta-data Application Profile

            Meta-data Multiplicity Requirements

            Content Aggregation

            0 or More (SPM 40)

            Content Organization

            0 or More (SPM 40)

            Activity

            0 or More (SPM 40)

            SCO

            0 or More (SPM 40)

            Asset

            0 or More (SPM 40)

            If the <contribute> element is used, SCORM recommends the use of the <entity> element. The <entity> element describes who was involved with the development of the meta-data.

            Data Type: The <entity> element as a CharacterString element. The CharacterString has an SPM of 1000 characters (Refer to Section 4.2.11.1: CharacterString Data Type for more information). All entity values shall be represented in vCard [9] format. This allows systems to take the CharacterString represented by the <entity> element and process this CharacterString as a valid vCard.

            Example:


            <lom>

            <metaMetadata>

            <contribute>

            <role>

            <source>LOMv1.0</source>

            <value>creator</value>