SCORM 2004
Content Development Guide

Version 1.04

March 2006

The e-Learning Consortium, JapanSCORM 2004 Content Development Guide

Copyright © 2006. The e-Learning Consortium, Japan. All Rights Reserved.

iSCORM 2004 Content Development Guide

Document Revision History
Date
December 2005
February 2006
March 2006

Version
1.01
1.03
1.04

Remarks
Translated from the Japanese document.
Editorial correction
Editorial correctionii

SCORM 2004 Content Development Guide

Table of ContentsDocument Revision History ...........................................................................................ii
Table of Contents ............................................................................................................i
1
Introduction............................................................................................................3
2
SCORM 2004 Overview........................................................................................4
2.1 What is SCORM? ............................................................................................4
2.2 Origins of the SCORM Standard .....................................................................4
2.3 The LMS Model...............................................................................................5
2.4 SCORM 2004 Overview..................................................................................5
2.5 Changes from SCORM 1.0 to SCORM 1.2.....................................................7
2.6 Changes from SCORM 1.2 to SCORM 2004..................................................82.6.1 Change to the Versioning of SCORM ......................................................82.6.2 Addition of the Sequencing Feature .........................................................82.6.3 Triggering Navigation Requests from SCOs ............................................92.6.4 Changes to the SCORM Run-Time Environment ....................................92.6.5 Changes to the SCORM Content Aggregation Model............................10
2.7 Future Evolution of SCORM .........................................................................11
3
Sequencing...........................................................................................................12
3.1 Content Structures and Learning Objectives .................................................12
3.2 Tracking Information .....................................................................................143.2.1 Tracking Objective Status and Completion Status .................................143.2.2 Information about Learning Time and Attempt Count ...........................15
3.3 Navigation Requests, Sequencing Requests, and Termination Requests ......16
3.4 Sequencing Rules...........................................................................................18
3.4.1 Sequencing Control Modes.....................................................................19
3.4.2 Limit Conditions .....................................................................................21
3.4.3 Precondition Sequencing Rules ..............................................................21
3.4.4 Post-Condition Rules and Exit Action Rules..........................................24
3.4.5 Rollup Rules............................................................................................25
3.4.6 Local Objectives and Shared Global Objectives ....................................32
3.4.7 Shared Global Objectives and Rule Evaluations ....................................34
3.5 Attempts.........................................................................................................35
4
Navigation............................................................................................................36
4.1 Navigation Control Overview........................................................................36
4.1.1 SCO Navigation in SCORM 1.2.............................................................36
4.1.2 SCO Navigation in SCORM 2004..........................................................37
4.2 Triggering a Navigation Event and SCO Termination ..................................37
4.2.1 SCO Navigation Event Triggered by an SCO ........................................37
4.2.2 Navigation Request Event and SCO Termination ..................................38
4.2.3 Validity of Navigation Request Events...................................................39
4.3 Controlling LMS-Provided Navigation Devices ...........................................40
5
Run-Time Environment (RTE) ............................................................................42
5.1 SCORM 2004 Run-Time Environment Overview ........................................42
5.2 Launching Content Objects............................................................................43
5.2.1 Assets ......................................................................................................43
5.2.2 SCOs .......................................................................................................43
5.3 API .................................................................................................................44
5.3.1 API Overview .........................................................................................44i

SCORM 2004 Content Development Guide
5.3.2 API Instance Overview ...........................................................................44
5.3.3 Using the API Instance ...........................................................................45
5.3.4 API Method Overview............................................................................47
5.3.5 API Instance State Transitions................................................................51
5.3.6 API Error Code Overview ......................................................................52
5.4 Data Model.....................................................................................................58
5.4.1 Data Model Overview.............................................................................58
5.4.2 Data Model Basics ..................................................................................58
5.4.3 SCORM Run-Time Environment Data Model .......................................63
6
Features of SCORM 2004 Content ......................................................................72
6.1 Sequencing Features ......................................................................................72
6.1.1 Specifying Sequencing Strategies...........................................................72
6.1.2 Specifying Sequencing Control Modes ..................................................72
6.1.3 Specifying Sequencing Rules .................................................................75
6.1.4 Specifying Rollup Rules .........................................................................80
6.1.5 Specifying Limit Conditions...................................................................85
6.1.6 Specifying Objectives .............................................................................86
6.1.7 Specifying Other Controls ......................................................................91
6.2 Features of SCORM 2004 SCOs ...................................................................94
6.2.1 RTE Usage Examples .............................................................................94
6.2.2 Example Uses of Navigation ................................................................1047
Migration from SCORM 1.2 to SCORM 2004..................................................107
7.1 Manifest File and SCOs ...............................................................................107
7.2 Converting the Manifest File .......................................................................107
7.2.1 Basic Structure ......................................................................................107
7.2.2 Content Packaging ................................................................................108
7.2.3 Changes to the Prerequisites and Masteryscore Elements....................108
7.2.4 Defining Sequencing Control Modes....................................................110
7.2.5 Metadata Description ............................................................................111
7.3 SCO Migration.............................................................................................112
7.3.1 API Instance Name Change ..................................................................112
7.3.2 API Method Name Changes .................................................................112
7.3.3 Changes to Data Model Elements.........................................................112
7.4 Changes to Error Codes ...............................................................................117
7.5 The Potential of SCORM 2004....................................................................118
Index...........................................................................................................................119
About This Document.................................................................................................121ii

SCORM 2004 Content Development Guide

1 Introduction
The Sharable Content Object Reference Model (SCORM) has been adopted in Japanas the standard for Web-based e-learning content and learning system development
for a few years. During this time, learning management systems (LMS) products,
content products and tools that are conformant to SCORM have been widely usedboth in Japan and overseas. The SCORM standard that has been generally used so far
is SCORM Version 1.2, which was released in 2000. Although large quantities of
SCORM 1.2 conformant products are widely used, some concerns have been raised as
to their functional deficiencies, ambiguities in the specifications and other matters. In
2004, the ADL (Advanced Distributed Learning Initiative) released a new standard
called SCORM 2004 in an effort to resolve such concerns and deficiencies in thestandard. The purpose of this handbook is to provide a technical overview of this new
standard and an explanation of the newly added features and the differences fromSCORM 1.2 and its intended audience is those who have some knowledge of SCORM.
SCORM 2004 not only introduces the new features of sequencing and navigation, but
it also provides an entire range of detailed specifications. And it is believed that the
new standard will satisfy most of the requirements expected by the e-learning industry
and the user community. However, the amount of technical content of SCORM 2004
exceeds some 800 pages in all, and it is not easy to grasp the big picture from theindividual technical books. To assist those who have some knowledge of SCORM 1.2
and wish to know about SCORM 2004, this handbook covers an overview of the
SCORM 2004 standard, the newly added features, and the differences from SCORM
1.2. It is anticipated that the readers will find it easier to understand the standard ifthey read this handbook first and then scan through the standard books.
Although this document discusses useful points in implementing SCORM 2004 to
give a better understanding of the standard mainly to content developers, it isexpected to be a useful guide to those who are involved in the planning, design anddevelopment of e-learning, not just to the content developers.
The list below shows the SCORM 2004 technical books and their acronyms that thishandbook uses as references.
OV: SCORM 2004 2nd Edition Overview
CAM: SCORM Content Aggregation Model Version1.3.1
RTE: SCORM Run-Time Environment Version 1.3.1
SN: SCORM Sequencing and Navigation Version 1.3.1
CR: SCORM Conformance Requirements Version 1.3
ADD: SCORM 2004 2nd Edition Addendum Version 1.2

3

SCORM 2004 Content Development Guide

2 SCORM 2004 Overview
This section describes the significance of the e-learning standard, emphasizing the
newly added features in SCORM 2004 and the changes from SCORM Version 1.2.

2.1 What is SCORM?
SCORM is the Sharable Content Object Reference Model documented andmaintained by the Advanced Distributed Learning Initiative (ADL) of the UnitedStates of America. It is intended to provide a common standard that will enable thesharing of learning content by making it• Durable• Interoperable• Accessible• Reusable
SCORM is a foundation reference model. E-learning content based on SCORM canbe used without change regardless of any changes to the hardware and softwareenvironment (durability), can run in any operating system and Web browser
environment (interoperability), can be searched for and discovered whenever required(accessibility) and can be used to develop new learning content (reusability).

2.2 Origins of the SCORM Standard
The SCORM standard and specifications are derived from work done by various
industry and technology organizations, including the IMS Global Learning
Consortium (IMS), the Aviation Industry CBT Committee (AICC), and the Instituteof Electrical and Electronics Engineers Learning Technology Standards Committee(IEEE LTSC). Using these specifications and guidelines, SCORM defines aframework for application to learning content, its aggregation, and its packaging.
SCORM also defines a set of conformance requirements for systems that will deliver
such content to the learner. SCORM has been influenced by the following:
SCORM 2004 CAM• IEEE Learning Object Metadata (LOM)•IMS Content Packaging•

IEEE Extensible Markup Language (XML) Schema Binding for Learning
Object Metadata Data Model

SCORM 2004 RTE• IEEE Data Model For Content Object Communication•

IEEE ECMAScript Application Programming Interface for Content to
Runtime Services Communication

SCORM 2004 SN• IMS Simple Sequencing.

4SCORM 2004 Content Development Guide

2.3 The LMS Model
Figure 2.1 shows a generalized learning management system (LMS) model. As shown,an LMS provides various services such as a learner profile service and a content
management service. However, SCORM does not address the specific implementationof such services. It provides a set of specifications only for the interface points
between learning content and the LMS. It merely defines the rules for registeringcontent to the LMS, launching the content and exchanging data between the content
and the LMS.
Testing /Assessment
ServiceSequencing
Service
Local Content
Repository

CourseAdministration
Service

Content
Management
Service
Learner Profile
Service

Remote Content
Repository

Selection

Tracking
Service

SCORM
Content
Package

DeliveryService
LaunchSCORM Run-Time
Environment Data

SCORM Content(SCOs and Assets)

API
Instance

Web Browser(Presentation)

Figure 2.1 An LMS Model

2.4 SCORM 2004 Overview
The ADL released SCORM 2004 in 2004 as the successor standard to SCORM 1.2.
SCORM 2004’s most significant difference from its predecessor is the addition ofsequencing and navigation features. Thanks to the enhancements introduced in the
new standard, content developers can enjoy more freedom in their content design anddevelopment. For example, the dynamic behavior of content in response to thelearning experience sequence and the learner’s progress – which could not be
described under the earlier versions – can now be controlled by the content. To
complement LMS-provided user interface devices for navigation, content can now
trigger navigation request events to allow use of the content’s own navigationcommand buttons like [Next] and [Back].
The specifications and standards of SCORM 1.2 were bundled into three technicalbooks: the SCORM Overview book, the SCORM Content Aggregation Model bookand the SCORM Run-Time Environment book. For SCORM 2004, the SCORM
Sequencing and Navigation book has been added to cover the sequencing andnavigation specifications, so there are now four technical books.

5

SCORM 2004 Content Development Guide(1) The SCORM 2004 Overview Book
This book describes the history and objectives of the ADL Initiative and SCORM. It
also covers the specifications and standards the SCORM has borrowed, and explains
how the SCORM books relate to each other.
(2) The SCORM Content Aggregation Model (CAM) Book
This book covers what content developers should know when they design SCORM
compliant learning content; that is, it provides a set of guidelines on how to describe
the identity of learning content components, and explains how to assemble andpackage the components. These guidelines are based on IEEE Learning Object Model(LOM) 1484.12, the AICC guidelines on content structure, IMS Content Packaging
and IMS Simple Sequencing.
The major SCORM technical topics covered in this book are sharable content objects(SCOs), assets, content aggregation, content packaging, the package interchange file(PIF), metadata, the manifest file, sequencing and navigation.
(3) The SCORM Run-Time Environment (RTE) Book
This book covers the requirements of the learning management system (LMS) for
managing a Web-based Run-Time Environment in terms of launching a learning
content object, exchanging data with the content object, and tracking the learner’s
progress. These guidelines are based on IEEE Application Programming Interface(API) 1484.11.2 and IEEE Data Model 1484.11.1.
The major SCORM technical topics covered in the book include the Application
Programming Interface (API), the API Instance, content object launch, session data
support methods, and the Run-Time Environment Data Model.
(4) The SCORM Sequencing and Navigation (SN) Book
This technical book has been added for SCORM 2004, and it marks the mostsignificant evolution of SCORM. This book provides guidelines on sequencing; i.e.,
how to deliver content to the learner. These guidelines are based on the IMS
Sequencing Information and Behavior Model. Guidelines on the navigation and userinterface devices are also based on this specification.
The major SCORM technical topics covered in this book include activity trees,
objectives, sequencing information, navigation information, and the run-timenavigation data model.
While each of the SCORM technical books focuses on specific aspects of SCORM,
there are some overlapping areas among the books, and those areas are described insuch a way that they can be easily referred to from each other.

6

SCORM 2004 Content Development Guide

Figure 2.2 SCORM Books (Source: SCORM 2004 2nd Edition Overview by ADL)

2.5 Changes from SCORM 1.0 to SCORM 1.2
Many changes have been made in the SCORM specification from the previous
SCORM versions. The forces behind this revision include the need to clarify concepts
and requirements, changes resulting from standardization efforts, the adoption of bestpractices from the ADL community, and the provision of enhancements and bug fixes.
SCORM entered its experimentation and evaluation step with SCORM 1.0. The
participants in the experimentation and evaluation effort regarding SCORM 1.0 raised
a number of questions and issues based on what they encountered during theimplementation.
Instead of expanding the scope of SCORM 1.0 in the new version, the specifications
and guidelines were modified and improved in SCORM 1.1 on the basis of the
feedback from the early participants.
The most noticeable change introduced in SCORM 1.1 was a name change. That is,while SCORM was an acronym for the Sharable Courseware Object Reference Modelin SCORM 1.0, it has stood for the Sharable Content Object Reference Model fromSCORM 1.1 onwards. This reflects the reality that the standard and specifications in
SCORM are applied to various levels of content rather than just courseware as awhole. Another significant change in SCORM 1.1 was that the standards andspecifications were subdivided into different functional groups to improve ease of use.

7

SCORM 2004 Content Development Guide
There were two more notable changes introduced in SCORM 1.1. First, a few data
model elements were removed from the run-time data model as a result of asimplification introduced to the AICC CMI Recommendations and Guidelines, uponwhich the SCORM run-time data model was based. Second, a major improvement
was made in the API for the Run-Time Environment.
In SCORM 1.2, the SCORM content package application profile was added on thebasis of the IMS Content Packaging specifications. In addition, metadata was updated
to reflect the latest specifications developed by IMS and IEEE LTSC. This update
included changes made to the data model and XML binding specifications.
Furthermore, from this version onwards the metadata application profile was renamed
the SCORM Content Aggregation Model and a new naming convention was adopted
to match the IMS Content Packaging specifications.

2.6 Changes from SCORM 1.2 to SCORM 2004
This section describes the changes and improvements made in SCORM 2004
compared to SCORM 1.2.

2.6.1 Change to the Versioning of SCORM
To improve the independence and maintainability of the SCORM technical books, theversioning of SCORM has been changed as from SCORM 2004 to allow each
SCORM book to have its own version, as in CAM and RTE “Version 1.3”. Futurechanges will apply only to those books affected and will be reflected in their version
numbers only.

2.6.2 Addition of the Sequencing Feature
For SCORM 2004, sequencing and navigation specifications have been added as a
new SCORM technical book. Learning sequence controls were not part of the
SCORM specifications up to SCORM 1.2, but they can now be described. For
example, the delivery sequence of learning content can now be controlled bychanging the type and sequence of the content to be learned based on the result ofpretesting done before the start of a lesson. In this case, a learner is regarded as having
completed a course after successfully answering questions A and B, while a learner
who does not answer successfully is asked to repeat the lesson or repeatedly go
through explanation screens before taking the test again; this continues until alearning objective is met.
Thus, it is now possible for content developers to control content behavior bydescribing a content structure and its associated sequencing rules in the manifest file.
As a learning path or status can be defined by combining various conditions, such as
how the learner satisfies an objective and how he or she progresses through the lesson,
content developers can now create adaptable content or a simulation package specificto a particular learner.

8

SCORM 2004 Content Development Guide

2.6.3 Triggering Navigation Requests from SCOs
The SCORM 2004 Sequencing and Navigation book introduces a specification
regarding the navigation requests that can be made from SCOs.
SCOs are allowed to trigger navigation request events such as [continue] and[previous] from within the SCOs. In addition, SCOs can now request whether LMSprovided navigation user interface (UI) devices are to be shown or hidden.
To enable an SCO to trigger a navigation event, the content developer should add an
API method call in the SCO that will set a value to a run-time data model element.
The content developer should also add a description in the manifest file regarding
how to control LMS-provided UI devices.
The new specification allows content developers to design a navigation function,
which is an important content factor, without regard to the type of LMS under which
the content will run.

2.6.4 Changes to the SCORM Run-Time Environment
The Run-Time Environment specification has been greatly changed in SCORM 2004
from SCORM 1.2. This section briefly summarizes these changes.
(1) API Instance Name Change
The API Instance has been renamed from API to API_1484_11.
(2) API Method Name Change
Table 2.1 Changes to API Methods
SCORM1.2
SCORM2004
LMSInitialize(“”)
Initialize(“”)
LMSFinish(“”)
Terminate(“”)
LMSGetValue(parameter)
GetValue(parameter)
LMSSetValue(parameter_1,parameter_2) SetValue(parameter_1,parameter_2)
LMSCommit(“”)
Commit(“”)
LMSGetLastError()
GetLastError()
LMSGetErrorString(parameter)
GetErrorString(parameter)
LMSGetDiagnostic(parameter)
GetDiagnostic(parameter)(3) Data Model Change
The major changes are as follows:•••

All data model elements defined in SCORM must be implemented andsupported by the LMS.
The data model has been flattened in SCORM, and the cmi.core andcmi.student_data elements have been removed.
The data model element for the interactions between an SCO and its RunTime Environment has become more sophisticated with the introduction of amore precise format for describing data concerning the learner’s responses totasks and responses to questions.

9SCORM 2004 Content Development Guide
•
•

•
•
•

As data model element names and their values are bound to character strings
encoded in Unicode (ISO 10646), multi-language implementation has beenrealized, including double-byte languages.
The lesson_status data model element has been removed, and in its place thecompletion_status and success_status elements have been introduced. The
possible state token values of the completion_status data model element arecompleted, incomplete, not_attempted or unknown to indicate whether thelearner has completed an SCO. The possible state token values of thesuccess_status data model element are passed, failed or unknown to indicate
whether the learner has mastered an objective. The browsed state token is nolonger used.
The score.scaled data model element has been introduced to indicate theperformance level of the learner for an objective. The old score.raw data
model element with a range from 0 to 100 points has been removed.
The objectives data model element is mapped with the learning objectives ofan activity, and shared global objectives can now be defined.
The introduction of a wider range of error codes makes it possible to check thestatus of the API Instance and the validity of data.

2.6.5 Changes to the SCORM Content Aggregation Model
The SCORM content aggregation model has been changed to reflect the introductionof sequencing and navigation specifications, and the affected XML schemas havebeen modified.
In addition, the following ADL content packaging extension elements were removed:•••<adlcp:prerequisites><adlcp:masteryscore><adlcp:maxtimeallowed>

The conditions that were previously defined with these elements are now described interms of corresponding sequencing rules.

10

SCORM 2004 Content Development Guide

Figure 2.3 SCORM Evolution

2.7 Future Evolution of SCORM
The ADL lists the following as future tasks for Web-based learning functions:• Designing new run-time and content data model architectures• Incorporating simulations• Incorporating electronic performance support objects• Implementing SCORM-based intelligent tutoring capabilities• Designing a new content model• Incorporating gaming technologies
Note, however, that the ADL has no current plans to release the next version.

11

SCORM 2004 Content Development Guide

3 Sequencing
This section explains the sequencing feature that is the main enhancement in SCORM
2004. It covers the basic concept of sequencing and its relationship with othercomponents, and explains how sequencing behaviors are described.
Figure 3.1 shows an overview of a sequencing behavior. Content developers control
the behavior of content by describing a content structure and a set of sequencing rules
associated with the structure in the manifest file (imsmanifest.xml). The LMS reads
the manifest file and performs actions described in the file. When it receives anavigation request from the learner, the LMS updates the learner’s status data (thetracking data) to reflect the learner’s progress status, interprets the sequencing rules,
decides on the next content to be delivered, and then delivers it to the learner’s
environment. The LMS repeats this process until the lesson is terminated.
The major components of sequencing and external functions are described with thefollowing:••••

Content structure and learning objectives
Tracking information
Navigation requests and sequencing requests
Sequencing rules

Run-time sequencing behaviors are described as a set of processes shown on the righthand side of Figure 3.1. The behavior of each process is defined as pseudo-code.
Section 6 gives a detailed explanation of the processes and pseudo-code. This section
explains the external functions of sequencing with the above four components.

3.1 Content Structures and Learning Objectives
In SCORM 2004, a content structure is described as a hierarchical tree structure. Eachnode in the tree is called an activity, and the content structure is represented as anactivity tree. An activity that has no child activity attached to it is called a leaf activity
and is associated with a learning resource (an SCO or asset) that can be delivered to
the learner’s screen.
When an activity has one or more child activities attached to it, the set is called acluster. For example, Activities 1.1.3, 1.1.3.1, and 1.1.3.2 in Figure 3.1 constitute acluster with Activity 1.1.3 as the parent, while Activities 1.1, 1.1.1, 1.1.2, and 1.1.3
constitute another cluster with Activity 1.1 as the parent. A cluster is the basic unit for
sequencing behavior, and in many cases the sequencing rules that are defined for aparent activity are applied to the cluster.
Each activity is always assigned with at least one objective, and this is called theprimary objective1. The role of the primary objective is discussed in the section on
1

The primary objective is also called a rollup objective. This name is given because it is represented by
the PrimaryObjective element in the manifest file. In the SN book, this is called the rollup objective
because among the objectives associated with an activity, this objective has the Objective Contributes

12

SCORM 2004 Content Development Guide
rollup below. Activities and objectives hold tracking information, which will be
discussed in Section 3.2. In addition to the default objective, content developers can
associate any number of global objectives to each activity. These global objectives
can be shared between multiple activities. Therefore an activity can be associated withmultiple shared global objectives in addition to the default objective, and each sharedglobal objective may be shared by multiple activities. A read and write relationshipcan be defined between a shared global objective and activities. The tracking
information status of a shared global objective is determined by the value of the
tracking information written from an activity. The activity can read the tracking
information of a shared global objective, and refer to it in the application ofsequencing rules. Shared global objectives are discussed in detail in Section 3.4.6.
Learner

Imsmanifest.xml
Read the manifest file.

1

Navigation Request

Activity
Objective

1.1
1.1.1

Interpret Navigation

Shared Global Objective
Sequencing Request&Termination Request

1.1.2

Read & Update

1.1.3
1.1.3.1

Cluster

Exit & Rollup
Sequencing Request
Sequencing

1.1.3.2
Delivery Request

1.2
Delivery
1.2.1
LMS

Figure 3.1 Sequencing Behavior Overview

To Rollup attribute set to True. They represent the same entity. The term “primary objective” is used in
the document.

13

SCORM 2004 Content Development Guide

3.2 Tracking Information
The tracking information is information that reflects the learner’s learning status, and
it is associated with each activity and its objectives. Table 3.1 shows the details of
tracking information.
The tracking information can be divided into data concerning learning performanceand completion on one hand and data concerning the learning time and number ofattempts on the other. An attempt here means a learner’s effort to complete an activity.
It refers to an effort from the time when an SCO is launched to the time when it isterminated. It may also refer to a learning effort that starts with a child activity of anintermediate parent activity and continues until the learner navigates out of thatcluster. An activity may be attempted more than once, so multiple attempts may exist
for an activity. The details of attempts are discussed in 3.5.

Objective Progress
Information
Objective Satisfied Status

Table 3.1 Tracking Model
Activity Progress
Attempt Progress
Information
Information
Attempt Completion Status

Objective Normalized
MeasureActivity Absolute
Duration
Activity Experienced
Duration
Activity Attempt Count

Attempt Completion
AmountAttempt Absolute Duration
Attempt Experienced
Duration

3.2.1 Tracking Objective Status and Completion Status
SCORM 2004 makes it possible to manage “completion” and “satisfaction”
independently. This is to accommodate a situation where a learner completes anactivity from start to finish but does not succeed in attaining its objectives, or asituation where the learner masters the content without completing the learning
activity.
“Satisfaction” is related to objectives, indicating whether the learner has satisfied or
not satisfied the objective or to what extent the learner has satisfied the objective.
These indications correspond to the Objective Satisfied Status and the Object Measure
Status elements of the Tracking Model shown in Table 3.1.
“Completion” is related to attempts on activities. It indicates whether the learner has
completed the attempt or not or to what extent the learner has completed the attempt.
These indications correspond to the Attempt Completion Status and Attempt
Completion Amount elements of the Tracking Model shown in Table 3.1.

14

SCORM 2004 Content Development Guide
These data elements of a leaf activity are updated by the associated SCO using the
Run-Time Environment Data Model. Table 3.2 shows the correspondence between
the Tracking Model and the Run-Time Environment Data Model.
In the case of a cluster, however, the status information about the parent activity is
updated based on its children’s status information. For the whole activity tree,
tracking information is propagated from SCO to leaf activity, then its parent, andfinally to the root activity of the activity tree. This recursive process is called a rollup2
behavior. A content developer decides how a parent activity’s information is to be
updated through a rollup process. Section 3.4.5 describes this rollup process.
Table 3.2 Correspondence between Tracking Model and
Run-Time Environment Data Model
Tracking Model
Run-Time Environment Data Model
Attempt Completion Status

cmi.completion.status

Attempt Completion Amountcmi.progress.measure

Objective Satisfied Status

Objective Normalized
MeasurePrimary
Objective

cmi.success.status

Other
Objectives

cmi.objectives.n.status

Primary
Objective

cmi.score.scaled

Other
Objectives

cmi.objectives.n.score.scaled

3.2.2 Information about Learning Time and Attempt CountThe amount of learning time with an activity is managed with the Attempt Absolute
Duration, Attempt Experienced Duration, Activity Absolute Duration, and Activity
Experienced Duration data elements.
The Attempt Absolute Duration refers to the duration from the start of one attempt tothe end of the attempt. The Attempt Experienced Duration refers to the duration fromthe start of one attempt to the end of the attempt, excluding the elapsed time while theattempt was suspended. If the attempt was not suspended, the values of these twoelements are identical.
The Activity Absolute Duration refers to the cumulative duration of all attempts on theactivity by a specific learner, and the Activity Experienced Duration refers to the
cumulative duration of all attempts (excluding suspensions) on the activity by aspecific learner.

2

An attempt’s completion amount is not subject to rollup in the current specification.

15

SCORM 2004 Content Development Guide
The Activity Attempt Count refers to the number of attempts on the activity by aspecific learner.
This information is collected at run-time by the LMS.

3.3 Navigation Requests, Sequencing Requests, andTermination Requests
Navigation requests refer to requests like [Continue] and [Previous] invoked by alearner. Table 3.3 shows the types of navigation requests. When a navigation request
is made by the learner from the Web browser, LMS-provided user interface devices
may be used or a request from the SCO may be honored. Section 5 explains how toissue a navigation request from an SCO.
A navigation request is translated into a termination request and a sequencing request
by the navigation interpretation process shown in Figure 3.1. Table 3.3 lists
navigation requests and the corresponding sequencing requests. Tables 3.4 and 3.5
explain each of them. A sequencing request triggers the launching of a wholelearning process, and traversal from one activity to another. A termination request
triggers the termination and suspension of a learning process.
Some sequencing requests and termination requests may be translated into othersequencing requests and termination requests by the post-condition rules shown in
Section 3.4.4. The Retry sequence request shown in Table 3.4 is generated by the
post-condition rules rather than with a navigation request. In response to a sequencing
request, the LMS switches from the current activity to another activity and decides on
the next activity to be delivered to the learner. In this case, the LMS processes thelimit conditions and precondition rules that are described in Sections 3.4.2 and 3.4.3.

16

SCORM 2004 Content Development Guide

Name
Start
Resume All
ContinuePrevious
ForwardBackward
ChoiceExit
Exit All
Suspend All

AbandonAbandon All

Name
Start
Resume All
ContinuePrevious
ChoiceExit
Exit All
Name
Exit
Exit All
Suspend All

AbandonAbandon All

Table 3.3 Navigation Requests
Sequence
RequestStart a new learning process on theStartactivity tree
Resume a suspended learning process
Resume Allon the activity tree
Proceed to the next activity
Continue
Go back to the previous activity
Previous
Not specified in the current version of
SCORM
Not specified in the current version of
SCORM
Proceed to the selected activity
ChoiceTerminate the current activity
Exit
Terminate the current activity and all of Exit
its ancestors in the tree
Terminate the current attempt on theExitcurrent activity and all of its ancestors
after saving the tracking information sothat the learning process may beresumed in the future
Abandon the current attempt on theExitcurrent activity
Abandon the current activity and all of
Exit
its ancestors in the tree
Description

Termination
Request

Exit
Exit

Exit
Exit
Exit All
Suspend All

AbandonAbandon All

Table 3.4 Sequencing Requests
Description
Start a new activity
Resume a suspended activity
Proceed to the next activity
Go back to the previous activity
Proceed to the selected activity
Terminate the current activity
Terminate the current activity and all of its ancestors in the tree
Table 3.5 Termination Requests
Description
Terminate the current activity
Terminate the current activity and all of its ancestors in the tree
Terminate the current attempt on the current activity and all of its
ancestors after saving the tracking information so that the activities
may be resumed in the future
Abandon the current attempt on the current activity
Abandon the current activity and all of its ancestors in the tree

17

SCORM 2004 Content Development Guide

3.4 Sequencing Rules
Sequencing rules are used by content developers to define sequencing behaviors. The
sequencing rules are broadly classified as explained below. Note that thesesequencing rules are defined for each activity.
• Rules limiting sequencing requests and transition behavior between activities.
These rules are applied on the basis of either a predetermined condition or the
tracking information. The former case is called a sequencing control mode.
For example, one of the sequencing control modes specifies whether eachchild activity in an activity tree can be accessed in the forward direction only
and reverse navigation is prohibited. The latter type of rules consist of
precondition rules, such as “if the Objective Satisfied Status is True, then theactivity is skipped,” and control condition rules, such as “the total
accumulated learning time for the activity must be less than 30 minutes.”• Rules for issuing a specific sequencing request when the tracking information
satisfies a certain condition. The rules of this type are called post-condition
rules. For example, “if the activity’s objective status is not satisfied, then retry
the activity.” Post-condition rules are evaluated at the Termination and Rollup
stage shown in Figure 3.1.
• Rules for updating tracking information. As discussed in Section 3.2, theobjective progress information for an activity is updated with a trigger event
generated when a learner provides some input to the current SCO. The
information is rolled up from the activity associated with the SCO through to
the root activity. This update process is called the rollup behavior. In theserules, it is possible to describe whether an activity is to contribute to the rollup,
conditions under which a rollup occurs, and an appropriate action to be taken
when a condition is met. For example, it is possible to describe a ruleindicating that “if three of its child activities are completed, then the parent
activity is regarded as completed.” These rules are evaluated at the
Termination and Rollup stage shown in Figure 3.1.
The types of sequencing rules discussed above can be summarized from thesequencing behavior standpoint as follows:(1) Tracking information update
Rollup rules are evaluated at the Termination and Rollup stage shown in
Figure 3.1, and the tracking information at each activity of the activity tree is
updated.
(2) Confirming a sequencing request
Post-condition rules are evaluated at the Termination and Rollup stage shownin Figure 3.1, and if the post-condition rules are satisfied, the sequencing
request based on the navigation request from the learner is replaced with thesequencing request generated by the precondition rule.
(3) Deciding on an activity for delivery
At the Sequencing and Delivery stages shown in Figure 3.1, a target activity is
selected for delivery. At this time, the next activity is selected with reference
to the sequencing control mode, precondition rules, and the limiting conditions.
Each type of sequencing rule is explained in detail in the sections below.

18

SCORM 2004 Content Development Guide

3.4.1 Sequencing Control Modes
Sequencing control modes control the sequencing behavior for a cluster, and they areclassified broadly into the following types:• Those used to make specific navigation requests effective (Sequencing
Control Choice, Sequencing Control Flow)• Those to add a limitation to transition between activities (Sequencing Control
Choice Exit, Sequencing Control Forward Only)• Those to control how to evaluate tracking information (Use Current Attempt
Objective Information, Use Current Attempt Progress Information).
Table 3.6 describes these sequencing control modes.
Table 3.6 Sequencing Control Modes
Name
Description
A Choice navigation request is permitted to
Sequencing Control Choicetarget the children of the activity
Sequencing Control Choice Exit

Sequencing Control Flow
Sequencing Control Forward Only
Use Current Attempt Objective
Information
Use Current Attempt Progress
Information

If false, it is prohibited to move from theactivity or its descendent to another activity
through the Choice navigation request
Continue and Previous navigation requests arevalid in the cluster
Backward movement is prohibited in thecluster
The Objective Progress Information for thecurrent attempt of the activity will be used inrule evaluations and rollup
The Attempt Progress Information for thecurrent attempt of the activity will be used inrule evaluations and rollup

3.4.1.1 Sequencing Control Choice and Sequencing Control Flow
The Sequencing Control Choice element is used to allow the learner to freely choose
an activity from a list of activities when the learner proceeds to the next activity. If theSequencing Control Choice element of a parent activity is set to True, then the learnercan proceed to any of the child activities with a Choice sequencing request. If thesequencing control mode value is False, the learner is not allowed to proceed to anyof the child activities with a Choice sequencing request.
The Sequencing Control Flow element is used to decide the delivery sequence of thechild activities of the target parent with a Continue or Previous sequencing request. If
the value of the Sequencing Control Flow element is True, the learner is allowed toproceed forward or backward to each child activity with, respectively, a Continue or aPrevious sequencing request. If the sequencing control mode value is False, thelearner is not allowed to move within the cluster with a Continue or Previous
sequencing request.

19

SCORM 2004 Content Development Guide
3.4.1.2 Sequencing Control Choice Exit
The Sequencing Control Choice Exit element is used to limit movement from theactivity or its child activities to another activity with a Choice sequencing request. If
the value of the Sequencing Control Choice Exit element of an activity is False, it is
not possible to proceed to another activity from that activity or its descendent
activities with a Choice sequencing request. For a Choice sequencing request to beeffective, the value of the Sequencing Control Choice Exit element defined for thecurrent activity and all its ancestor activities must be True. Therefore, this sequencing
control mode makes it possible to prohibit an exit from the set of activities below aparticular parent activity through a Choice sequencing request.
3.4.1.3 Sequencing Forward Only
The Sequencing Forward Only element is used to direct movement between activities
to forward only within a cluster, and to prohibit reverse movement. If the value of theSequencing Control Forward Only element of an activity is True, Previous andChoice sequencing requests are not allowed among its child activities. However, thesesequencing requests are valid if the value is False.
3.4.1.4 Use Current Attempt Objective Information and Use Current Attempt
Progress Information
These data elements are used to indicate whether the Attempt Objective Information
and Attempt Progress Information for the cluster will reflect only the information
gathered from the current attempt or use the latest information, including that from themost recent previous attempt on the cluster’s child activities. If the values of theseelements of the parent activity are True, the information from the current attempt onlyis reflected. At the current attempt on the associated cluster, the objective informationand progress information about the child activities that have not yet been delivered areconsidered “Unknown”. If the values of the Attempt Objective Information and
Attempt Progress Information elements are False, then the latest information,
including that from the most recent previous attempt, is used. At the current attempton the associated cluster, the objective information and progress information
regarding the child activities that have not yet been delivered are adjusted to theinformation at the end of the most recent previous attempt.
Figure 3.2 illustrates the above process. In Figure 3.2, the Attempt Objective
Information and Attempt Progress Information elements of the parent are set to Truein a) and False in b).

20

SCORM 2004 Content Development Guide
Use Current

Previous F= True

1.

1.1

1.2

1.3

Previous

T

F

T

Current

T

T

U

Current

U

Use Current= False1.

Previous F
Current T

1.1

1.2

1.3

T

F

T

T

T

U

Previous
Currentb)a)Figure 3.2 Use Current Attempt Objective and Progressive Information
In both cases, the objective satisfied and attempt completion status of the child
activities for the previous attempt are set to True for 1.1, False for 1.2 and True for1.3. In the case of Activity 1, the rolled up status is False, based on the default rollup
rule explained in Section 3.4.5 for the And combination of 1.1, 1.2, and 1.3. At thecurrent attempt, activities 1.1 and 1.2 have been completed with 1.1 and 1.2 being set
to True.
How should the status information of parent activity 1 be determined in this situation?
If it is to be based on the current attempt information, the status of Activity 1 should
be set to Unknown (as shown in a) above) with the And combination of 1.1, 1.2, and
1.3 as Activity 1.3 has not been attempted. If the past information should also be
considered, on the other hand, the latest information not only about the current
attempt but also about the most recent previous attempt is considered, and the statusvalue of Activity 1 becomes True (as shown in b) in the diagram) because the statusof 1.3 was True at the previous attempt. Content developers may choose which
information is used for each cluster.

3.4.2 Limit Conditions
A limit condition can be defined to indicate that an activity is not allowed to bedelivered. The only means of implementing a limit condition under the current
SCORM specifications is to use the Limit Condition Attempt Count element. If an
attempt count limit is defined for an activity, that activity cannot be attempted formore than the specified number of times.

3.4.3 Precondition Sequencing Rules
Precondition sequencing rules are used to define conditions for limiting the deliveryof activities. These rules are similar to limit conditions in the sense that they are used
to control the delivery of activities.
Precondition rules are defined for each activity, and more than one rule may be
defined for one activity. The precondition sequencing rules are described in thefollowing format:
If [condition set]

Then [action].

21

SCORM 2004 Content Development Guide

The condition set is a collection of conditions to be evaluated as True or False withrespect to the tracking information for the activity. The action part indicates what
limit is to be imposed on the delivery of the activity. Some example precondition
sequencing rules are shown below:
If Satisfied Then Skip
If the objectives of the activity are satisfied, it is to be skipped.
If Attempted Then Disabled
If the activity has been attempted, the delivery of the activity is to be disabled.
If Always Then Hidden from Choice
At all times, this activity must not be used as a Choice navigation target.
3.4.3.1 Condition Set of Precondition Sequencing Rules
The condition set of a precondition sequencing rule is defined in the following format:
condition_combination ((condition_operator, condition_element), ….)Therefore, a condition set is one or more pairs of a condition operator and a condition
element combined with a condition combination. Each of these elements is explained
below.
•••

Condition combination: There are two condition combination elements: All andAny. When All is used as a condition combination, the condition set is evaluatedas True only if all the subsequent condition elements are evaluated as True. If the
Any condition combination is used, the result of the condition set becomes True
if any one condition element is evaluated as True. The default condition
combination is Any.
Condition operator: There are two types of rule condition operator: NO-OP and
Not. The NO-OP condition operator does not change the Boolean value of thecorresponding condition element. The Not condition operator negates theBoolean value of the condition element.
Condition element: The evaluation result of a rule condition element depends on
the tracking information for the activity. Table 3.7 shows a list of rule condition
elements. If the target tracking information is the Objective Satisfied Status
information or the Objective Normalized Measure information regarding theactivity, the target objective is specified by the Rule Condition Referenced
Objective element. For the Objective Normalized Measure element, the target
threshold is specified by the Rule Condition Measure Threshold.

22

SCORM 2004 Content Development Guide

Condition
Satisfied

Table 3.7 List of Rule Condition Elements
Tracking
Description
information
Objective Satisfied The condition is evaluated as True if the
Objective Satisfied Status for the target
Statusobjective is True
The condition is evaluated as True unless the
Objective Satisfied Status for the target
objective is Unknown
The condition is evaluated as True unless the
Objective Normalized Measure for the target
activity is Unknown

Objective
Status Known

Objective Satisfied
StatusObjective
MeasureKnown

Objective
Normalized
MeasureObjective
MeasureGreater Than

Objective
Normalized
MeasureThe condition is evaluated as True if the
Objective Normalized Measure for the target
objective is greater than the Rule Condition
Measure Threshold

Objective
Measure Less
Than

Objective
Normalized
MeasureCompleted

Attempt
Completion Status

Activity
Progress
Known
Attempted

Attempt
Completion Status

Attempt Limit
Exceeded

Activity Attempt
Count

AlwaysNone

The condition is evaluated as True if the
Objective Normalized Measure for the target
objective is less than the Rule Condition
Measure Threshold
The condition is evaluated as True if the
Attempt Completion Status for the activity isTrue
The condition is evaluated as True unless the
Attempt Completion Status for the activity is
Unknown
The condition is evaluated as True if the
Activity Attempt Count for the activity is 1 ormore
The condition is evaluated as True if the
Activity Attempt Count for the activity is equal
to or greater than the Limit Condition Attempt
Limit for the activity
The condition is always evaluated as True

Activity Attempt
Count

3.4.3.2 Actions for Precondition Sequencing Rules
Table 3.8 shows a list of actions for precondition rules. These actions are applied
when the next activity for delivery is decided as shown in Figure 3.1.

23

SCORM 2004 Content Development Guide

Table 3.8 List of Actions for Precondition Rules
ActionDescription
This action is used for a situation where an activity for
Skip
delivery is to be selected during a traversal of anactivity tree with a Continue or Previous sequencing
request. If the condition for an activity is met, that
activity is skipped and the next in line activity in that
direction is checked for delivery possibility.
This action is used to prohibit the delivery of an
Disabled
activity. If the condition is True, that activity cannot bedelivered even when selected.
This action is used to hide an activity from the list of
Hidden from Choice
available activities for selection with a Choice
sequencing request. If the condition is True, theactivity is not included in the target for a Choice
sequencing request.
This action is used when the next activity is to be
Stop Forward Traversal
selected during a forward traversal of an activity tree.
If the condition is evaluated as True, the activities
following it will not be considered candidates fordelivery.

3.4.4 Post-Condition Rules and Exit Action Rules
Post-condition rules and exit action rules can be used to ignore a navigation requestfrom the learner and instead generate a sequencing request or termination request
designed by the content developer.
These rules are defined for each activity. One or more rules may be defined for one
activity. As with the precondition rules, these rules are defined in the form ofIf [condition set]

Then [action]

The condition set is a collection of conditions to be evaluated as True or False withrespect to the tracking information for the activity. The action part indicates asequencing request or a termination request.
Two examples of post-condition sequencing rules follow:
If Not Satisfied Then Retry
If the objective of the activity is not satisfied, then that activity is to be retried.
If All (Attempted, Satisfied) Then Exit All
If the activity has been attempted and the objective is satisfied, the wholelearning process is to be terminated.

24

SCORM 2004 Content Development Guide
3.4.4.1 Condition Set of Post-Condition Sequencing Rules and Exit Action
Rules
The condition part is defined in the same way as for precondition rules.
3.4.4.2 Actions for Post-Condition Sequencing Rules and Exit Action Rules
Table 3.9 shows a list of actions for post-condition rules and exit action rules. These
actions are applied when a new sequencing request or a termination request is to begenerated in place of the learner’s navigation request during the termination androllup process shown in Figure 3.1.
Table 3.9 Actions for Post-Condition Rules and Exit Action Rules
ActionDescription
Sequencing
Termination
RequestRequestTerminate the parent of
Exit Parent
Exit Parent
the current activity
Terminate the whole
Exit All
Exit All
learning process
Terminate the current
Exit
Exit
activity
Retry the current activity. Retry
Retry
If it is not a leaf activity,
retry the first child
activity of the cluster.
Terminate the whole
Retry
Exit All
Retry All
learning process andresumeMove forward
Continue
Continue
Move backward
Previous
Previous

3.4.5 Rollup Rules
In the Rollup process, the tracking information of each activity in an activity tree issuccessively rolled up from each leaf activity (SCO) towards the root activity. Rollup
rules are used to decide how the tracking information of a parent activity is rolled up
from the tracking information of its child activities.
Rollup rules are related to the Objective Satisfied Status data, the Objective
Normalized Measure data, and the Attempt Completion Status data. Figure 3.3 shows
the relationship between these three types of data.
In the measure rollup process, the Objective Normalized Measure data of the parent’s
primary objective is determined from the Objective Normalized Measure data for its
child activities’ primary objectives. Only one primary objective is associated witheach activity as described in Section 3.1.
The satisfied status of the primary objective of a parent activity is determined througha rollup process using the following data: its own Objective Normalized Measure datathat is rolled up from its child activities, the Objective Satisfied Status data of the25

SCORM 2004 Content Development Guide
primary objective, the Attempt Completion Status data, and the Activity Attempt Countdata of each child activity.
In the progress status rollup, the Attempt Completion Status data of a parent activity isdetermined from the Objective Satisfied Status data, the Attempt Completion Statusdata, and the Activity Attempt Count data of each child activity.
Each of these is explained below.
Child Activity
Child
Child

Parent Activity

Primary Objective
Primary Objective
Primary
Objective Measure
Objective Normalized
Objective Normalized Measure
Objective Normalized Measure
Objective Satisfied Status
Objective Satisfied Status
Objective Satisfied Status

Objective Measure Rollup

Primary Objective
Objective Normalized Measure

Objective Rollup
Objective Satisfied Status
Progress Status
RollupAttempt Completion Status
Attempt Completion Status
Attempt Completion Status

Attempt Completion Status

Activity Attempt Count
Activity Attempt Count
Activity Attempt Count

Figure 3.3 Tracking Information Relationship in a Rollup Process
3.4.5.1 Measure Rollup Process
The objective measure of a parent activity’s primary objective is determined by
calculating the weighted average of the objective measure for the primary objective ofeach child activity. The weight for an objective measure is specified by the content
developer using the Rollup Objective Measure Weight data item. The formula is asfollows.

The Objective Measure of a Parent=∑ ( RollupObjectiveMeasureWeight × ObjeciveNormalizedMeasure)child activity∑ RollupObjectiveMeasureWeightchild activity

If the Objective Normalized Measure value of a child activity’s primary objective is
Unknown, the calculation is performed as if the value is 0.
3.4.5.2 Objective Rollup
The objective rollup process determines the Rollup Objective Satisfied status of aparent activity through the following sequence:

26

SCORM 2004 Content Development Guide(1) Using Objective Measure
If the Objective Satisfied by Measure element of the parent activity is evaluatedas True, the Objective Satisfied Status element of the parent is determined bycomparing its Objective Normalized Measure value that has been calculated
through a measure rollup process against the value specified for the Objective
Minimum Satisfied Normalized Measure. If the rollup measure equals or exceeds
the value of the Objective Minimum Satisfied Normalized Measure, the Rollup
Objective Satisfied status is True; otherwise, it is False. The rollup process ends
here.
If the Objective Satisfied by Measure element of the parent activity is evaluatedas False, the activity’s status does not change and the rollup process proceeds to(2) below.
(2) Using Rollup Rules
If the rollup rules defined for the activity contain an action Satisfied or Not
Satisfied, the satisfied status of the primary objective is determined by evaluating
the Not Satisfied rule first and then the Satisfied rule. Therefore, the result of the
Not Satisfied rule evaluation may sometimes be overwritten by the result of theSatisfied rule evaluation. The objective rollup process ends here. The rollup rules
will be discussed in more detail later.
If the actions of the rollup rules for the parent activity do not include Satisfied or
Not Satisfied, the rollup process proceeds to the evaluation of the default rules asshown in (3) below.
(3) Using Default Rules
The following default rules are evaluated in the same way as in (2) above.
If all (attempted or not satisfied), Then not satisfied
If all satisfied, Then satisfied
That is,If all the activities are attempted or their Objective Satisfied Status values are
not True, the Rollup Objective Satisfied status is False.
If the Objective Satisfied Status values of all child activities are True, then
the Rollup Objective Satisfied status of the parent activity is True.
3.4.5.3 Activity Progress Rollup Process
In the progress rollup process, the Rollup Completion Status of a parent activity isevaluated through the following sequence.
(1) Using Rollup Rules
If the rollup rules defined for the activity contain an action Completed or
Incomplete, the attempt completion status is determined by evaluating theIncomplete rule first and then the Completed rule. Therefore, the result of the
Incomplete rule evaluation may sometimes be overwritten by the result of theCompleted rule evaluation. The progress rollup process ends here. The rollup
rules are discussed below in more detail.
27

SCORM 2004 Content Development Guide
If the actions of the rollup rules for the parent activity do not include Completed
or Incomplete, the rollup process proceeds to the evaluation of the default rules
as described in (2) below.
(2) Using Default Rules
The following default rules are evaluated in the same way as in (1) above.
If all (attempted or incomplete), Then incomplete
If all completed, Then completedThat is,If the Attempt Completed Status values of all child activities are True, then
the Rollup Completion Status is True.
If all the activities are attempted or their Attempt Completion Status values
are True, the Rollup Completion Status is True.
3.4.5.4 Rollup Rules in Detail
The Satisfied and Not Satisfied rollup rules for an objective rollup and the Completed
and Incomplete rollup rules for an activity progress rollup process are both defined in
the following format:
If [condition_set]

For [child_activity_set]

Then [action]

The above rule format means that each rollup rule consists of a child_activity_set,
which is a set of child activities to consider, a condition_set, which is a set of
conditions that are to be evaluated against the tracking information of the included
child activities, and an action, which is a corresponding action that sets the cluster’s
tracking status information if the final result of applying the set of conditions to thechild activity set is evaluated as True.
Examples of the rollup rules are shown below.
If not satisfied For any Then not satisfied
If any child activity is not satisfied, then the cluster is not satisfied.
If satisfied For at least 3 Then satisfied
If at least three child activities are satisfied, then the cluster is satisfied.
If satisfied or completed For all Then completed
If all child activities are satisfied or completed, then the cluster is completed.
If satisfied and attempted For all Then satisfied
If all child activities are satisfied and attempted, then the cluster is satisfied.
If not attempted For at least 50% Then incomplete
If at least 50% of the child activities are not attempted, then the cluster isincomplete.

28

SCORM 2004 Content Development Guide►Rollup Condition Set
A condition set of a rollup rule is defined in the following format:
condition_combination ((condition_operator, condition_element), ….)This is in the same format as for precondition sequencing rules (Section 3.4.3.) The
two rule condition combination elements (All and Any) and the two rule condition
operators (Not and NO-OP) are the same as those in precondition rules.
The rule condition elements of a rollup rule differ from those of a precondition or
post-condition sequencing rule. Table 3.10 shows a list of condition elements used inrollup rules. The differences from those of a precondition or post-condition
sequencing rule are that, first, there is no condition element for comparing the valuesof objective measures, and second, as the target objective is limited only to theprimary objective value, no objective is specified.
►Rollup Child Activity Set
The Rollup Child Activity Set element is used in a rollup rule to define how todetermine the final evaluation result of True or False from the application of thespecified condition set to the child activities. For example, a rollup rule can be defined
specifying that if 80% of the child activities satisfy the specified condition set, thenthe final result is set to True. Table 3.11 shows a list of rollup child activity elements.

Condition
Satisfied

Table 3.10 List of Rollup Rule Condition Elements
Tracking
Description
Information
Objective Satisfied The condition is evaluated as True if the
Objective Satisfied Status for the primary
Statusobjective is True

Objective
Status Known

Objective Satisfied
StatusObjective
MeasureKnown

Objective
Normalized
MeasureCompleted

Attempt
Completion Status

Activity
Progress
Known
Attempted

Attempt
Completion Status
Activity Attempt
Count

The condition is evaluated as True unless the
Objective Satisfied Status for the primaryobjective is Unknown
The condition is evaluated as True unless the
Objective Normalized Measure for the primaryobjective is Unknown
The condition is evaluated as True if the
Attempt Completion Status for the activity isTrue
The condition is evaluated as True unless the
Attempt Completion Status for the activity is
Unknown
The condition is evaluated as True if the
Activity Attempt Count for the activity is 1 or
more

29

SCORM 2004 Content Development Guide
Condition
Attempt Limit
Exceeded

Tracking
Information
Activity Attempt
Count

Never

None

Name
All

Any

None

At Least CountAt Least Percent

Description
The condition is evaluated as True if the
Activity Attempt Count for the activity is equal
to or greater than the Limit Condition Attempt
Limit for the activity
The condition is always evaluated as False

Table 3.11 List of Child Activity Sets
Description
If the condition combination of all child activities isevaluated as True, then the specified rollup action isappliedIf the condition combination of any child activity isevaluated as True, then the specified rollup action isappliedIf none of the child activities contains a condition
combination that is evaluated as True, then thespecified rollup action is applied
If the number of activities that contain a condition
combination evaluated as True is at least equal to thenumber specified by the Rollup Minimum Countelement, then the specified rollup action is applied
If the percentage of activities containing a condition
combination evaluated as True is at least equal to thenumber specified by the Rollup Minimum Percent
element, then the specified rollup action is applied

How to specify a child activity set which is to be subject to a rollup rule is discussed
here. In general, the tracking status data for all child activities is used in the rollup
evaluations of the parent activity. However, a content developer can selectively
include or exclude certain activities from the rollup child activity set for rollup
evaluations. For example, when the At Least Count element is used for a rollup
activity child set definition in a rollup rule, the number of child activities containing a
condition combination evaluated as True can be calculated by excluding child
activities from the target rollup child activity set under the following circumstances:•

A child activity whose Tracked element is defined as False, which means thatno tracking status data is maintained for the activity, is never included during
rollup.

•A child activity whose Rollup Objective Satisfied element is defined as False
is not included in the evaluation of rollup rules having a Satisfied or Not
Satisfied rollup action.
A child activity whose Rollup Progress Completion element is defined as
False is not included in the evaluation of rollup rules having a Completed or
Incomplete rollup action.
A child activity that has various Required for rollup elements defined, whichindicate, conditionally, when an activity is included in the evaluation of rollup

•
•

30

SCORM 2004 Content Development Guide
rules having specified rollup actions, might not be included. Required forrollup elements are shown in Table 3.12.

31

SCORM 2004 Content Development Guide

Table 3.12 List of Required for Rollup Elements
Name
Description
Vocabulary (common)
Indicates when the action
Required for Satisfied• always – To be always
is considered in theconsidered.
Satisfied rollup rule
• ifNotSuspended – To be
Indicates when the action
Required for Not
considered when the childis considered in the Not
Satisfied
activity has been
Satisfied rollup ruleattempted but is not
Required for Completed Indicates when the actionsuspended at the time ofis considered in theevaluation
Completed rollup rule
• ifAttempted – To be
Indicates when the action
Required forconsidered when the childis considered in the
Incomplete
activity has been
Incomplete rollup ruleattempted at the time ofevaluation• ifNotSkipped – To beconsidered if the child
activity has not beenskipped at the time ofevaluation►Rollup Rule Actions
The Rollup Rule Action element specifies one of four actions, Satisfied, Not Satisfied,Completed, or Incomplete, that will be applied to the parent activity to which rollup
rule is associated. Rollup Rule Actions are shown in Table 3.13.
Rollup action
Satisfied
Not Satisfied
Completed
Incomplete

Table 3.13 List of Rollup Actions
Description
The Objective Satisfied Status of the rollup objective
for the associated parent activity is set to True
The Objective Satisfied Status of the rollup objective
for the associated parent activity is set to False
The Attempt Completion Status of the rollup objective
for the associated parent activity is set to True
The Attempt Completion Status of the rollup objective
for the associated parent activity is set to False

3.4.6 Local Objectives and Shared Global Objectives
Each activity is associated with one local objective by default. Moreover, a course
developer can specify any number of local objectives for a given activity as required.
These local objectives can be associated with shared global objectives. The sharedglobal objectives enable activities to share tracking information for sequencing. The
introduction of global objectives makes it possible, for example, for the content
developer to define a situation where a learner is led through a tutorial activity or canskip it depending on the result of a pretest activity. Figure 3.4 shows the relationships
between activities, local objectives and shared global objectives.

32

SCORM 2004 Content Development Guide

Activity
Local Objective

A1
A1.1

LO1.1A
LO1.1B

A1.2

LO 1.2B
LO 1.2C

A1.3
A1.4

Shared Global Objective

LO 1.3A

SO A

LO 1.3B

SO B

LO 1.4B
LO 1.4C

SO C

Figure 3.4 Relationships between Activities, Local Objectives
and Shared Global Objectives
There are limitations, though, on how activities are related to local and shared global
objectives:• An activity may have more than one local objective. For example, refer to therelationship of A1.1 with LO1.1A and LO1.1B in Figure 3.4.
• One local objective can be related to only one shared global objective. For
example, refer to the relationship between LO1.1A and SO A.
• One shared global objective can be related to more than one local objective. For
example, refer to the relationship of SO B with LO1.1B, LO1.2B, and LO1.4B.
• The above means that one activity can be related to shared global objectives
through the activity’s associated local objectives. For example, refer to therelationship of A1.1 with SO A and SO B.
• From the perspective of a shared global objective, one shared global objective canbe related to multiple activities through its connection with the local objectives of
those activities. For example, refer to the relationship of SO B with A1.1, A1.2,
and A1.4.
When a local objective is connected to a shared global objective, the direction fortransmission of the objective measure and satisfaction status data should be defined.
That is, whether the local objective data is to be written to the shared global objective
data or the shared global objective data is to be read to a connected local objective
should be defined. The following restriction is applied in this situation:• For a given activity and a shared global objective, the information from only one
local objective can be written to that shared global objective, and the sharedglobal objective data cannot reflect information from any other local objective.
For example, refer to the relationship of SO B with LO1.1B, LO1.2B, andLO1.4B in Figure 3.4.

33

SCORM 2004 Content Development Guide

3.4.7 Shared Global Objectives and Rule Evaluations
3.4.7.1 Shared Global Objectives with Precondition, Post-Condition and Exit
Rules
As discussed in 3.4.3 Precondition Sequencing Rules and 3.4.4. Post-Condition Rulesand Exit Action Rules, the condition part of these rules can refer to the local
objectives associated with the activity. If the connection between a local objective of
the activity and a shared global objective is defined in such a way that the informationfrom the shared global objective is to be read into the local objective, the informationfrom the shared global objective is used in the rule evaluation.
3.4.7.2 Shared Global Objectives and Rollup Rules
As described in Section 3.4.5 Rollup Rules, only the primary objective of an activity
is used for rollup. If the primary objective of an activity is connected to a sharedglobal activity, the shared global objective information is affected by the rollup rules.
Figure 3.5 shows the relationship between rollup and shared global objectives. Rollup
rules are evaluated on the basis of each leaf activity whose tracking information haschanged because of a state transition on the associated SCO and the activities whichrefer to the shared global objective whose value is written from the leaf activity. The
collection of activities that is the base for rollup is called a rollup set. If there is achange to the tracking information of Activity A1.1.1 in Figure 3.5, for example, therollup set includes three activities: A1.1.2 and A.1.2, which read the value reflecting
the state change from the shared global objective SO B, and A.1.1.1.

Activity

Local Objective

Shared Global Objective

A1
A1.1

A1.2

LO1.1

SO A

A1.1.1LO1.1.1

A1.1.2

LO 1.2.1

A Rollup Set

LO 1.2C

SO B

A1.2.1

LO 1.2.1

A1.2.2

LO 1.2.2

Figure 3.5 Relationships between Shared Global Objectives and Rollup
If a rollup process originating from an activity in the rollup set reaches anotheractivity in a rollup set, the second activity is removed from the rollup set. Furthermore,
if the information regarding a shared global objective is updated during a rollup
process to reflect a change in the state of an associated local objective of an activity,

34

SCORM 2004 Content Development Guide
no separate rollup behavior occurs among the other activities that refer to that sharedglobal objective. In Figure 3.5, for example, although the tracking information of
A1.1 is affected by the rollup behavior from A.1.1.1 and the shared global objective
SO A reflects this change, the change is not propagated to A1.2.1.

3.5 Attempts
An attempt refers to a learning effort from the point at which an activity is delivered
to the learner and the learner starts the activity to the point at which the learnercompletes the activity and another activity is selected for delivery. If an activity has
been completed during an attempt and that activity is selected and delivered again,
this is regarded as a separate attempt.
Attempts are managed in terms of parent and child relationships in an activity tree.
Therefore, if A1.1.2 in Figure 3.6 is being currently attempted, for example, A1.1.2,
A1.1, and A1 are all regarded as being attempted. If a learner has selected A1.1.1 after
having completed A1.1.2 in this case, A1.1.2 is regarded as completed but A1.1 andA1 are still regarded as being attempted.
An attempt can be suspended by a Suspend All navigation request. An attempt on an
activity can be resumed from the suspended state through a Resume All navigation
request. A resumed attempt is not regarded as a new attempt, but as a continuation of
the suspended attempt.

A1
A1.1
A1.1.1A1.1.2A leaf activity being currently attempted

A1.2
A1.2.1Figure 3.6 Attempts

35

SCORM 2004 Content Development Guide

4 Navigation
This section explains the navigation feature that has been added to SCORM 2004. Itcovers the basic navigation concepts from a broad perspective, implications of thenavigation feature for user interface implementation, and how navigation behavior
can be specified.

4.1 Navigation Control Overview
4.1.1 SCO Navigation in SCORM 1.2
The specifications of SCORM 1.2 stipulate that all navigation controls between SCOs
should be provided by the LMS. For example, the user interface controls required forthe presentation of an SCO and the transition from that SCO to another SCO must be
provided by the LMS under SCORM 1.2. In other words, content developers had nosay on the navigation behavior between SCOs, and thus could not provide navigation
buttons from one SCO to another.
In addition, SCORM 1.2 did not define how an LMS should manage the navigation
behavior of SCOs. This made it difficult to provide consistent user interfaces since theuser interfaces differed, depending on each LMS, with respect to the presence orabsence of buttons and menus and their display positions on the screen, as well as intheir captioning and navigation methods. That is, these limitations on navigation
control design hindered content developers creating content for multiple LMS
environments under SCORM 1.2 who wanted to design and provide user interfaces
with a consistent look and feel.

SCOs must be controlled by a LMS.
Different navigation interfaces dependingon the LMS.
Menu Frame

No navigation control
for another SCO wasallowed in a SCO

Displayed byLMS

SCO Frame

API FrameSCO

API Adapter

Figure 4.1 An Example of SCOM 1.2 Navigation Implementation

36

SCORM 2004 Content Development Guide

4.1.2 SCO Navigation in SCORM 2004
In SCORM 2004, a set of new specifications has been added for managing thenavigation methods of SCOs and content developers can now control the navigationof SCOs. More specifically, SCOs can now issue SCO navigation requests andrequest that the LMS display or hide navigation buttons.
This new functionality enables content developers to standardize a consistentnavigation design, considered an important goal in content development, without
taking into account the type of LMS environment in which the content will be used.
Note that the LMS does not interfere with the navigation control within an SCO (or an
asset) under SCORM 2004 or SCORM 1.2, and the content developer must consider
all aspects of this.

The navigation buttons provided
by the LMS can be controlledfrom the content side.

Menu Frame

Displayed byLMS

SCO FrameSCO
A SCO canimplement SCO
navigation controls.

API Frame

API Instance

Figure 4.2 An Example of SCORM 2004 Navigation Implementation

4.2 Triggering a Navigation Event and SCO Termination
4.2.1 SCO Navigation Event Triggered by an SCOIn SCORM 2004, a set of navigation events like Continue and Previous can betriggered from an SCO. These events are now available in addition to the SCO
navigation requests issued by an LMS that could be used in previous SCORM
versions. The navigation events triggered by an SCO are processed in the same way
as those triggered by an LMS.
The navigation events that can be triggered from an SCO are listed in Table 4.1.

37

SCORM 2004 Content Development Guide
Table 4.1 Navigation Events that can be Triggered from an SCO
Navigation event
Behavior description
This event leads to the termination of the current SCO
continueand the issuing of a continue navigation request
This event leads to the termination of the current SCO
previousand the issuing of a previous navigation request
This event leads to the termination of the current SCO
choiceand the issuing of a choice navigation request
This event leads to the ending of the current attempt on
exit
the current activity, and to the issuing of an exit
navigation request
This event leads to the ending of the current attempt on
exitAllthe current activity tree and all the associated activities,
and to the issuing of an exit all navigation request
This event leads to the ending of the current attempt onabandonthe current activity, and to the issuing of an abandon
navigation request
This event leads to the ending of the current attempt onabandonAll
the current activity tree and all the associated activities,
and to the issuing of an abandon all navigation request
This event leads to the clearing of all navigation requests_none_
that are not yet processed
The navigation requests that are generated by navigation events triggered by an SCO
are considered valid for processing in conjunction with sequencing control modes inthe same way as SCO navigation requests issued by an LMS. A sequencing control
mode specified on a cluster defines the navigation requests that can be applied to thecluster’s child activities.
If the Sequencing Control Choice is valid, for example, a choice navigation request isapplied to the child activities of the cluster. In the same way, if the Sequencing
Control Flow is valid, a continue or previous navigation request can be applied to thechild activities of the cluster.

4.2.2 Navigation Request Event and SCO Termination
To allow an SCO to trigger a navigation event, an element called adl.nav.request has
been introduced in the navigation data model of SCORM 2004. An SCO triggers anavigation event in the runtime environment or in the LMS by calling a SetValuefunction with a value like continue, previous, choice or exit for the adl.nav.request
navigation data model element in the following format:
SetValue(“adl.nav.request”,<REQUEST>)

where <REQUEST> is one of the following: continue, previous,
choice, exit, exitAll, abandon, or abandonAll.
Note that to trigger a choice navigation event, it is necessary to specify the identifierof an activity to be delivered. The format is as follows:
SetValue(“adl.nav.request”, “{target =<STRING>}choice”)

where <STRING> indicates the item identifier of the target activity.
38

SCORM 2004 Content Development Guide

When an SCO has communicated a navigation request using an API method call to
the LMS with a navigation request event, the LMS performs a sequencing process
based on the navigation request after having accepted the termination processing of
the SCO. Even if a navigation request has been communicated to the LMS, the LMS
does not immediately respond to it, but starts processing the request only when it has
accepted a termination request from the SCO.
An SCO may repeatedly invoke the function for a navigation request event manytimes, but each time it invokes that function the value set by the SCO is replaced with
the new value provided in the latest function call. This means that the only event to be
responded to is the last navigation request event that is recorded after the LMS has
completed processing a terminate request from the SCO.

SetValue(“adl.nav.request”, “continue”)
Terminate(“”)

Figure 4.3 An Example Use of a “continue” Navigation Event

4.2.3 Validity of Navigation Request Events
To enable SCOs to check with the LMS as to whether a navigation request continue,
previous, or choice is valid, a new element (adl.nav.request_valid.REQUEST) has
been added as a navigation data model element. When this query is made by an SCO,
the LMS returns a value indicating whether the request is valid. The query result isTrue if the request is valid, False if it is not valid, and Unknown if the validity is notknown.
GetValue(“adl.nav.request_valid.<REQUEST>”)

where <REQUEST> is continue, previous or choice.
Return value: true, false or unknown
To check whether a choice navigation request is valid, the identifier of the target
activity must be specified as shown below.
GetValue(“adl.nav.request_valid.choice {target=<STRING>}”)

where <STRING> indicates the item identifier of the target activity.

39

SCORM 2004 Content Development Guide
In addition, an SCO can confirm the value that is currently set to the adl.nav.request
element through the GetValue method. The value returned from a GetValue method
call is the value currently stored at the data element on the LMS side. If there is novalue set to the element, _none_, which is the initial value of adl.nav.request, isreturned.
GetValue(“adl.nav.request”, <REQUEST>)

where <REQUEST> is one of the following: continue, previous,
choice, exit, exitAll, abandon, or abandonAll.

4.3 Controlling LMS-Provided Navigation Devices
SCORM 2004 allows a content developer to specify whether the user interface
devices of the LMS are to be hidden or shown. By including navigation request eventsin SCOs and specifying the user interface device control on the LMS, content
developers can introduce their own design policies to their content user interface andcontent organization.
It is possible to specify whether to show or hide the LMS-provided user interface
devices corresponding to the continue, previous, exit and abandon navigation requests
by defining an appropriate token as the value of the hideLMSUI element for eachactivity in the manifest file (imsmanifest.xml). Table 4.2 shows a list of vocabulary
tokens that can be used with the hideLMSUI element.
Table 4.2 Tokens for Controlling LMS-provided Navigation Devices
Token
Description
Hide the Previous navigation device
previous
Hide the Continue navigation device
continue
Hide the Exit navigation device
exit
Hide the Abandon navigation device
abandonThe example below specifies a situation where the Continue and Previous navigation
user interface devices provided by the LMS will not be displayed at the run-time for
Activity “item1”.
<organization><item identifier=”item1” identifierref=”Resource1” isvisible=”true”><adlnav:presentation><adlnav:navigationInterface><adlnav:hideLMSUI>continue</adlnav:hideLMSUI><adlnav:hideLMSUI>previous</adlnav:hideLMSUI></adlnav:navigationInterface></adlnav:presentation></item></organization>

40

SCORM 2004 Content Development Guide

Without hideLMSUI specified

With hideLMSUI specified

Figure 4.4 Displaying and Hiding LMS-provided Navigation Devices

41

SCORM 2004 Content Development Guide

5 Run-Time Environment (RTE)
The section describes the SCORM Run-Time Environment that lies between learning
resources like SCOs and the LMS. It covers the changes made to the Run-Time
Environment of SCORM 2004 from that of SCORM 1.2.

5.1 SCORM 2004 Run-Time Environment Overview
The SCORM Run-Time Environment (RTE) book describes a common launchingcontent object mechanism of learning resources, a common communication
mechanism between learning resources and the LMS, and a common data model for
handling the tracking information for managing each learner’s performance andprogress with the learning resources. In a Run-Time Environment, an SCO that has
been delivered with the use of an Application Programming Interface (API) instancecommunicates with the LMS (Figure 5.1).

Server Side

Content

Client Side

Item1
Item1.1
Item1.1.1
Item1.1.2
Item1.2

SCORM
RTE

API

(Communication link
between SCO and LMS)

API Instance(Provided by LMS)

Platform

Web Browser

LMS
Data Model

Figure 5.1 SCORM 2004 Run-Time Environment
The launching process defines common methods used by the LMS to launch Webbased learning resources. This mechanism specifies the methods and responsibilities
for establishing a communication session between the LMS and a Content Object thathas been delivered. The communication mechanism is standardized with a common
API.
The API is a communication mechanism for sending status information regarding theContent Object (for example, regarding the initialization, termination, and error
status) and is used for setting or getting data between the launched SCO and the LMS.
The API Instance in Figure 5.1 indicates a software component that is provided by the
LMS for a launched SCO to locate and use for communication with the LMS in an
ECMAScript compatible language (e.g., JavaScript).

42

SCORM 2004 Content Development Guide

The data model is a standard set of data elements defined for storing and referencing
the necessary information to be tracked such as the completion status of an SCO andthe score from a quiz or test assessment. The LMS and SCOs are implemented in sucha way that the LMS and the SCOs communicate with each other using the data model
elements under the assumption that the other party knows the meanings and uses ofthese data model elements.

5.2 Launching Content Objects
The LMS is responsible for determining a learning activity to be attempted based on anavigation request, and then delivering an associated learning resource for the learner.
When delivering a learning resource, the LMS launches the target resource using the
URL that has been defined as the launch location for the learning resource. A launchmethod may be implemented either on the client side or the server side, but thelearning resource whose launch location is defined using the HTTP protocol isdisplayed on the Web browser window of the client.
There are two types of learning resource that can be launched by the LMS: SCOs andassets.

5.2.1 Assets
An asset refers to a resource consisting of digital media such as text and images thatcan be loaded through a Web browser. An asset does not communicate with the LMS.
An asset does not need to include a function called to the API that is provided by theLMS.

5.2.2 SCOs
The standard specifies that as a collection of one or more assets, a Sharable Content
Object (SCO) should communicate with the LMS using the Run-Time Environment.
An SCO is the minimum resource unit whose behavior can be recorded and managed
by the LMS.
It is also specified in SCORM that only one SCO can be launched by the LMS at agiven time and one SCO can be activated.

43

SCORM 2004 Content Development Guide

SCO1.2

SCO1.1

Not Allowed to Launch another SCO

LaunchAPI Instance(Provided by LMS)LMS

Web browser

Figure 5.2 Launching a SCO

5.3 API
5.3.1 API Overview
Prior to its current version (SCORM 2004), SCORM was based on the AICC CMI001
Guidelines for Interoperability. The AICC has submitted its work to the IEEE
Learning Technology Standards Committee (LTSC) as a candidate to become aninternational standard. SCORM has adopted the IEEE 1484.11.2-2003 Standard for
Learning Technology – ECMAScript Application Programming Interface for Content
as the standard for Runtime Services (RTS) communication. Adopting a common API
made it possible for SCORM to meet its high-level requirements concerninginteroperability and usability. The API provides a standardized way for SCOs tocommunicate with LMSs, and also enables LMS implementers to encapsulate theirown specific implementation details from content developers. The LMS has toprovide the API, API Implementation and API Instance that SCOs need tocommunicate.

5.3.2 API Instance Overview
An API Instance3 is a piece of software that implements and exposes the necessary
API methods, and it is provided to an SCO by the LMS as an interface through which
the SCO can communicate with the LMS. Content developers must develop theircontents (SCOs) in such a way that they can locate this API Instance provided by the
LMS.
An important aspect of the API is that it allows an SCO to communicate with the
LMS. Once an SCO has been launched, the SCO can store (SetValue) or refer to(GetValue) the data that the LMS is keeping for the SCO. Communication between
the API Instance and an SCO is realized by invoking the methods of the API Instance.
The name of the API Instance is “API_1484_11”4 in SCORM 2004.
3
4

The API Instance was called the API adapter in SCORM versions prior to 1.2.
The API Instance name has been changed from “API” to “API_1484_11” in SCORM 2004.

44

SCORM 2004 Content Development Guide

5.3.3 Using the API InstanceTo establish a communication session with the LMS, a launched SCO must find theinstance of the API implementation object that has been provided to it by the LMS.
This means that the SCO must recursively search the parent windows and opener
window for the API Instance. In this case, the LMS must make the API Instanceavailable in the Document Object Model (DOM) context as an object called“API_1481_11”.
5.3.3.1 LMS Responsibilities
The LMS must provide an API Instance under the following conditions:• The LMS must make it possible for SCOs to access the API Instance in the DOM
context with the name of “API_1481_11”.
• The LMS must enable the SCO to access the API Instance using ECMAScript(JavaScript) code.
• The LMS must launch an SCO in a child window of the window where the API
Instance has been loaded or in a child frame of the LMS window.
API
AP 1484
Opener Window

Parent 3
Parent 2
Parent 1

SCO

SCO

API
AP 1484
1484
API
AP 14841484
Parent 4

Parent 3
Parent 2

Opener Window

Parent 1
SCO

Figure 5.3 Permitted Location of an API Instance45

SCORM 2004 Content Development Guide
5.3.3.2 SCO Responsibilities
SCOs must be developed in such a way that they can establish a communication
session with the LMS by searching for the API Instance. For an SCO to find the API
Instance located in a DOM window, it must search in the following sequence:
1. Search the chain of parents of the current window until the top window of theparent chain is reached.
2. Search the opener window (window.opener), which was the window opened by
the SCO.
3. Search the chain of parents of the opener window, if any exist, until the top
window of the parent chain is reached.

Parent N
Parent 2
Parent 1
SCO

Chain of Parents

Parent N
Parent 2
Parent 1

SCO

Chain of Parents of the Opener
Figure 5.4 Finding the API Instance
The minimum amount of communication that an SCO must have with the LMS after
locating the API Instance is the invocation of the Initialize(“”) and Terminate(“”)
functions. The IEEE standard has provided a simple piece of ECMAScript that can beused to find the API Instance in a consistent manner. However, the standard does not
require use of this ECMAScript code. Other means can be adopted.

46

SCORM 2004 Content Development Guide

5.3.4 API Method Overview
The API methods are classified into three categories as shown below.
Category
SessionMethods
Data-transfer
Methods
Support
Methods

Table 5.1 Categories of API Methods
Description
Session methods are used to mark the beginningand end of a communication session between an
SCO and an LMS through the API Instance.
Data-transfer methods are used to exchange data
model element values between an SCO and an
LMS through the API Instance.
Support methods are used for auxiliarycommunications (e.g., error handling) between
an SCO and an LMS through the API Instance.

API methods
Initialize
Terminate
GetValue
SetValue
CommitGetLastError
GetErrorString
GetDiagnostic

In SCORM 2004, the names of the API methods provided by the LMS have beenchanged. (As the LMS prefix has been dropped from the names, it has become easierto recognize the names.)
Table 5.2 Changes to API Method Names
SCORM 1.2
SCORM 2004
LMSInitialize
Initialize
LMSFinish
Terminate
LMSGetValue
GetValue
LMSSetValue
SetValue
LMSCommit
CommitLMSGetLastError
GetLastError
LMSGetErrorString
GetErrorString
LMSGetErrorDiagnostic
GetErrorDiagnostic

47

SCORM 2004 Content Development Guide
The syntactic details of the API methods are shown in Table 5.3.

Initialize

Terminate

Table 5.3 List of API Methods
Session Methods
Syntax: Initialize (parameter)
Description: This method is used to initialize a communication
session.
Parameter: (“”) an empty character string
Return value: A character string indicating a Boolean value (true or
false).
”true”: Indicates that the initialization on the LMS side was
successful.
”false”: Indicates that the initialization on the LMS side was
not successful. In this case, the API Instance sets an error
code. Support methods are used to interpret the error data.
Syntax: Terminate (parameter)
Description: This method is used to terminate the communication
session. The termination process should also transmit thedata that the SCO has set with the API Instance but has not
yet been stored in the LMS. Once this method has been
executed, it is not possible to call any support methods.
Parameter: (“”) an empty character string
Return value: A character string indicating a Boolean value (true or
false).
”true”: Indicates that the termination on the LMS side was
successful.
”false”: Indicates that the termination on the LMS side was
not successful. In this case, the API Instance sets
an error code. Support methods are used tointerpret the error data.

48

SCORM 2004 Content Development Guide

GetValue

SetValue

Data Transfer Methods
Syntax: GetValue(parameter)
Description: This method is used to request information fromthe LMS. The SCO can request the following
information from the LMS:
• The values of the data model elements supported by
the LMS• The version of the data model supported by the LMS• Whether specific data model elements are supported
Parameter: The parameter indicates the identification of thetarget data model element.
Return value: One of two types of character string:• A character string representing the value of the data
model element indicated by the parameter• An empty character string (“”) when an error occurs.
In this case, the API Instance sets an error code.
Support methods are used to interpret the error data.
Syntax: GetValue(parameter_1, parameter_2)
Description: This method is used to set the value indicated byparameter_2 as the value of the data element indicatedby parameter_1 at the LMS. The data may be instantly
transmitted to the LMS or sent in a batch after being
cached for a while, depending on the design as follows:• The values of the data model elements supported by
the LMS• The version of the data model supported by the LMS• Whether specific data model elements are supported
Parameter: parameter_1 indicates the name of the target data
element
parameter_2 indicates the value to be stored (a character
string)Return value: A character string indicating a Boolean value(true or false).
”true”: Indicates that the data transfer to the LMS side
was successful.
”false”: Indicates that the data transfer to the LMS side
was not successful. In this case, the API
Instance sets an error code. Support methods
are used to interpret the error data.

49

SCORM 2004 Content Development Guide

CommitGetLastError

Data Transfer Methods
Syntax: Commit(parameter)
Description: This method is used to commit stored data fromthe SCO to the LMS. If there is any data from the SCO
that has been cached by the API Instance since the lastcall to Initialize(“”) or Commit(“”), whicheveroccurred most recently. If the commit is successful, the
LMS sets the error code to “0” (no error encountered)and returns “true”. If the API Instance does not cacheany data, this method is processed in the same way as
above.
Parameter: (“”) an empty character string.
Return value: A character string indicating a Boolean value(true or false).
”true”: Indicates that the commit process on the LMS
side was successful.
”false”: Indicates that the commit process on the LMS
side was not successful. In this case, the API
Instance sets an error code. Support methods
are used to interpret the error data.
Support Methods
Syntax: GetLastError()
Description: This method is used to request the error code forthe latest error state of the API Instance. The API
Instance does not alter the state of the current error upona call of this method by the SCO, and simply returns theerror code.
Parameter: No parameter is specified.
Return value: A character string indicating the error code forthe current error state.

50

SCORM 2004 Content Development Guide
GetErrorString

GetDiagnostic

Syntax: GetErrorString(parameter)
Description: This method is used to request a textual
description of the current error state. The API Instanceshould guarantee the support for the error code
implemented at the API. The API Instance does not alter
the state of the current error upon a call of this methodby the SCO, and simply returns a character string whichis the error description.
Parameter: A character string indicating a target error code.
Return value: A character string representing the error message
corresponding to the error code indicated by theparameter.
• The maximum length of a return value character
string is 255 characters.
• While a set of error codes is explicitly specified by
SCORM, the description of each error code is
specific to the LMS.
• When the LMS cannot identify the error code, an
empty character string (“”) is returned.
Syntax: GetDiagnostic(parameter)
Description: This method is provided for specific use of the
LMS. It allows the LMS to define additional diagnostic
information through the API Instance.
Parameter: An implementer-specific value for diagnostics. The
maximum length of the parameter value is 255
characters. An error code may be used as the parameter,
but the parameter can also be used for other purposes.
Return value: A character string representing the diagnostic
information that is implemented by the LMS. The
maximum length of a return value character string is
255 characters.
Note: If the GetDiagnostic() function is called with an empty
character string (“”) as the parameter, it is recommended thatthe function should return a character string representing
diagnostic information about the last error encountered.

5.3.5 API Instance State Transitions
A conceptual model has been defined to specify the transitions of the API Instanceduring execution. The states of the API Instance indicate the transitions of the API
Instance for specific events. These states are defined as• Not Initialized• Running• Terminated51

SCORM 2004 Content Development Guide

Running

Initialize(“”)

SCO is Launched
Not Initialized•Initialize()•GetLastError()•GetErrorString()•GetDiagnostic()

Terminate(“”)•Terminate()•SetValue()
Terminated•GetValue()•Commit()•GetLastError()•GetLastError()•GetErrorString()•GetErrorString()•GetDiagnostic()•GetDiagnostic()

Figure 5.5 API Instance State Transitions and SCORM API(1) Not Initialized
This is a state where no communication session has been established. It is the state
before the SCO has successfully invoked the Initialize API method. The SCO ispermitted to call the following set of API functions:• Initialize()• GetLastError()• GetErrorString()• GetDiagnostic()(2) RunningThis is a state in which the SCO exchanges data with the LMS after establishing acommunication session. The SCO is permitted to call the following set of API
methods:• Terminate()• SetValue()• GetValue()• Commit()• GetLastError()• GetErrorString()• GetDiagnostic()(3) TerminatedThis is a state in which the SCO has successfully invoked the Terminate function. The
SCO is permitted to call the following set of API methods:• GetLastError()• GetErrorString()• GetDiagnostic()

5.3.6 API Error Code Overview
All error codes are character strings representing integers (0 – 655535). The IEEE
standard has reserved codes between 0 and 999. Additional error codes may be

52

SCORM 2004 Content Development Guide
defined by implementers using the remaining numbers from 1000 to 655535. The
IEEE has defined the error code categories shown in Table 5.4.
Table 5.4 Categories of Error Codes
Error Code Range Description0
The LMS returns this value
when there is no error
General Errors
100 – 199
Errors that occur during thehandling of API methods
Syntax Errors
200 – 299
Syntax errors found in the
invoked API methods
RTS Errors
300 – 399
Errors associated with theimplementation of the runtime system
Data Model Errors
400 – 499
Errors in the data sent to the
LMS or the data received
from the LMS
Implementation-defined1000 - 65535
For LMS implementers toErrorsuse for their specificpurposesError Code Category
No Error

Table 5.5 shows the details of the API implementation errors.
Code
0
101
102

103

104

111
112

Table 5.5 API Error Code Details
Message
Description
No ErrorThis code is returned when there
is no error state.
GeneralGeneral errors occurred during
Exception
the processing of API method
requests.
GeneralAn error occurred during theInitialization initialization process of a
Failurecommunication session. The
communication state remains“Not Initialized”.
Already
After the communication was
Initialized
successfully established, theSCO attempted to initialize it
again.
Content
The SCO attempted to invoke
Instance
the Initialize method after theTerminatedcommunication session was
terminated.
GeneralA general failure occurred when
Termination
an attempt was made to
Failureterminate the session.
Termination
The SCO attempted to terminate
Beforea communication session before
Initialization initializing the session.

53

API Methods
All methods
Initialize()

Initialize()

Initialize()

Initialize()

Terminate()

Terminate()

SCORM 2004 Content Development Guide
Code
113

Message
Termination
After
Termination

122

Retrieve Data
BeforeInitialization

123

Retrieve Data
After
Termination

132

Store Data
BeforeInitialization

133

Store Data
After
Termination

142

Commit Before
Initialization

143

Commit After
Termination

201

GeneralArgument Error

301

General Get
Failure351

General Set
FailureDescription
The SCO attempted to terminate
the communication session after
the communication session was
successfully terminated.
The SCO attempted to retrieve
data before it successfully
initialized a communication
session.
The SCO attempted to retrieve
data after termination of thecorresponding communication
session.
The SCO invoked a SetValue
method of the API Instance tostore data before it successfully
initialized a communication
session.
The SCO invoked a SetValue
method of the API Instance tostore data after termination of
the corresponding
communication session.
The SCO invoked a Commit
method to save its data to apersistent store in the LMS
before it successfully initialized
a communication session.
The SCO invoked a Commit
method to save its data to apersistent store of the LMS aftertermination of its
communication session.
An attempt was made to pass aninvalid argument to the invoked
API method.
A general failure occurred
during the attempt to retrieve therequested data and there is noother error information
available. The communication
state remains “Running” in thissituation.
A general failure occurred
during the attempt to set therequested data and there is noother error information
available. The communication
state remains “Running” in thissituation.
54

API Methods
Terminate()

GetValue()

GetValue()

SetValue()

SetValue()

Commit()Commit()Initialize()
Terminate()
Commit()GetValue()

SetValue()SCORM 2004 Content Development Guide
Code
391

Message
General Commit
Failure401

Undefined Data
Model Element402

Unimplemented
Data Model
Element

403

Data Model
Element Value
Not
Initialized

404

Data Model
Element Is
Read Only
Data Model
Element Is
Write Only
Data Model
Element Type
Mismatch

405
406

407

Data Model
Element Value
Out Of Range

Description
A general failure occurred
during the attempt to commit thedata and there is no other error
information available. The
communication state remains“Running” in this situation.
The invoked API method
contains a parameter that the
API Instance cannot recognize.
The communication stateremains “Running” in thissituation.
The invoked API method
contains a parameter that has notbeen implemented by the LMS.
The communication stateremains “Running” in thissituation.
This should not occur whenaccessing SCORM data model
elements, but may occur whenaccessing extension data model
elements.
The SCO attempted to retrieve
the value of a data model
element that has not been
initialized. Note that some data
model elements are initialized
by an SCO while others are
initialized by the LMS.
The SCO attempted to set a newvalue to a read-only data model
element.
The SCO attempted to retrieve
the value of a write-only data
model element.
The SCO attempted to store avalue that was of an incorrect
data type for the target data
model element.
The SCO attempted to store aninvalid value that was outside
the specified range for the target
data model element.

55

API Methods
Commit()GetValue()
SetValue()

GetValue()
SetValue()

GetValue()

SetValue()

GetValue()

SetValue()

SetValue()SCORM 2004 Content Development Guide
Code
408

Message
Data Model
Dependency Not
Established

Description
API Methods
GetValue()
This error code is designed for
SetValue()
handling a situation where an
SCO attempts to read the value
from, or write a value to, a data
model element that has adependence relationship definedwith one or more other elements
when the dependence has not yet
been established.

56

SCORM 2004 Content Development Guide
Table 5.6 compares the SCORM 1.2 and SCORM 2004 error codes in conjunction
with the API Instance state transitions.
Table 5.6 Comparison of Error Codes between SCORM 1.2 and SCORM 2004
SCORM 1.2 Error CodeSCORM 2004 Error Code0 – No error
101 – General Exception

201 - Invalid argument error
202 - Element cannot have children
203 - Element not an array. Cannot
have count401 - Not implemented error
401 - Not implemented error
301 - Not initialized
403 - Element is read only
404 - Element is write only
402 - Invalid set value, element isa keyword

0 No error
101 - General Exception
102 - General Initialization Failure
103 - Already Initialized
104 - Content Instance Terminated111 - General Termination Failure
112 - Termination Before
Initialization
113- Termination After Termination
122 - Retrieve Data Before
Initialization
123 - Retrieve Data After Termination
132 - Store Data Before
Initialization
133 - Store Data After Termination
142 - Commit Before Initialization
143 - Commit After Termination
201 - General Argument Error
301 - General Get Failure
351 - General Set Failure
391 - General Commit Failure
401 - Undefined Data Model Element402 - Unimplemented Data Model
Element
403 - Data Model Element Value Not
Initialized
404 - Data Model Element Is Read Only
405 - Data Model Element Is Write
Only
406 - Data Model Element Type
Mismatch
407 - Data Model Element Value Out Of
Range
408 - Data Model Dependency Not
Established405 - Incorrect Data Type57

SCORM 2004 Content Development Guide

5.4 Data Model
5.4.1 Data Model Overview
The SCORM Run-Time Environment Data Model specification is based on the IEEEP1484.11.1 Draft Standard for Learning Technology – Data Model for Content
Object Communication. This standard defines a set of data model elements that can beused for communication from SCOs to the LMS. The data model includes, among
other things,• Information about the learner• Interactions between an SCO and the LMS• Objectives• Success status and completion status.
The data model elements are defined in such a way that they can be used for a varietyof content purposes.
The main uses of the Run-Time Environment data are• To track the learner’s progress and status• To support sequencing decisions• To report on the learner’s overall interactions with the SCO.
The SCORM Version 1.2 Run-Time Environment Data Model was based on the
AICC CMI001 Guideline for Interoperability. Since the release of SCORM Version
1.2, AICC has submitted CMI001 to the IEEE for standardization. SCORM 2004 has
introduced changes to the data model in accordance with the IEEE 1484.11.1 Draft
Standard. The major changes can be summarized as follows:• All data model elements have become mandatory for the LMS to implement.
• Changes to the data modelo Removal of cmi.core and cmi.student_data
o Addition of score.scaledo Addition of sequencing data model elements corresponding to
objectives• Detailed specification of interactions• Adoption of Unicode (ISO-10646-1) for multi-language implementation support,
including multi-byte code.

5.4.2 Data Model Basics
5.4.2.1 Data Model Elements
To differentiate them from the other data model elements, the names of all Run-Time
Environment Data Model elements start with “cmi”. This indicates to the LMS thatthese data model elements are part of the IEEE P148411.1 standard. It is anticipatedthat when a different data model is to be developed, its data elements will be namedwith a different prefix (for example, adl.elementName instead of cmi.elementName).
It is mandatory for the LMS to implement all these data model elements and toguarantee their behaviors.

58

SCORM 2004 Content Development Guide

Content developers can choose to use any or all of the data model elements in SCOs.
The names of all the data model elements must be bound to ECMAScript character
strings with dot notation (for example, cim.success_status).
5.4.2.2 Data Model Effects on Sequencing
Using the Run-Time Data Model elements, each SCO reports the results ofinteractions between the learner and the SCO to the LMS during a session. The LMS
uses the information reported from an SCO when it makes a sequencing decision as towhich activity is to be delivered next. For example, when an SCO reports its attempt
status as completed (by the learner) to the LMS using the data element“cmi.completion_status” (as tracking information), the LMS regards the activity
associated with the SCO as completed and selects another activity for delivery. Some
data model elements of the RTE are related to the tracking information for eachactivity, and thus affect the sequencing process.
5.4.2.3 Handling Collections
Some data model elements are collections of related elements defined for specificrequirements. Such collection data is referred to as a record of data in the SCORM
RTE book. Each record of data is collected as an entity in an array. The record of datais accessed using an index value representing the record of data’s position in the array.
All arrays are implemented with a starting index of 0 (zero-based arrays).
The following data model elements are defined as collections of data records:• Comments from learner (cmi.comments_from_learner)• Comments from LMS (cmi.comments_from_lms)• Objectives (cmi.objectives)• Interactions (cmi.interactions)
These data model elements are to ensure that SCOs can track multiple comments,
objectives and/or interactions. The Objectives and Interactions data model elements
contain an identifier data model element that indicates a unique identifier for each of
the SCO’s Objectives and Interactions.
The data model elements in a collection are referred to using a dot-number notation(represented as n in the following.)
cmi.objective.n.completion_status
For example, the value of the data model element representing the completion statusof the first objective in an SCO is described as “cmi.objective.0.completion_status”,
and that of the fourth objective is described as “cmi.objective.3.completion_status”.
The _count keyword data model element is used to determine the current number ofdata model elements in the collection. For example, to determine the number ofobjectives currently stored for the SCO, the following API method call would be
used:

59

SCORM 2004 Content Development Guidevar numOfObjectives = GetValue(“cmi.objectives._count”);

5.4.2.4 Smallest Permitted Maximum (SPM)
In SCORM 2004, the smallest permitted maximums (SPMs) are defined for the data
model elements in two cases. The SPM is defined as the length of a character stringvalue or the number of entries (data model elements) in collections; that is, the SPM isdefined as the smallest permitted length of a character string that any implementationmust accept and process or the smallest permitted number of entries in a collection.
An implementation may elect to support the storage of more than the SPM. If an
implementation only supports the SPM and truncates a character string, it is necessary
for content developers to be aware of the SPM and what may happen if it is exceeded.
5.4.2.5 Keyword Data Model Elements
SCORM defines a set of data model elements for getting the data managed by the
LMS and the status data of some data model elements. These data model elements arecalled keyword data model elements. The keyword data model elements can only beapplied to certain data model elements and are implemented as read-only data model
elements.
• _version: The _version keyword data model element is used to retrieve the versionof the data model supported by the LMS.
• _count: The _count keyword data model element is used to retrieve the number ofdata model elements contained in a collection.
• _children: The _children keyword data model element is used to retrieve theentire set of child data model elements included in a parent data model element
supported by the LMS. The LMS must implement the return value for this_children request as a list of character strings delimited by a comma, with eachstring representing a child data model element. This data model element can only
be applied to a data model element that has its child data model elements.
5.4.2.6 Reserved Delimiters
A special reserved delimiter must be used to represent• The language type for a particular character string (Data type:
localized_string_type)• The indication as to whether the order matters in the learner’s responses to aninteraction• The indication as to whether the case matters in the learner’s response to aninteraction• A set of values in a list or pairs of values.
For each of the above cases, a default value is provided where applicable. This default
value is used if the special reserved delimiter is not specified. In any case, thereserved delimiters should not be counted toward the value of the SPM.

60

SCORM 2004 Content Development Guide

Table 5.7 Reserved Delimiters
Reserved Delimiter Syntax
Default Value
Example{lang=<language_type>}{lang=en}{lang=en}{case_matters=<boolean>}{case_matters=
false}{case_matters=true}{case_matters=false}{order_matters=<boolean>}{order_matters=true}{order_matters=true}{order_matters=false}[.]

Not applicable. A Used to separate a pair ofvalues that are related for anvalue must be
interaction:
provided.
1[.]a

[,]

Not applicable. A Used to separate a set ofvalues for an interaction’svalue must becollection:
provided.
1[.]a[,]2[.]c[,]3[.]b[:]

Not applicable. A Used to represent a separator
between a range of numericvalue must bevalues:provided.
1[:]100 – a range where
the numeric value is between
1 and 100 (inclusive)

5.4.2.7 Data Types
Each of the data type elements has a designated data type. The values of a data model
element must satisfy the data type requirements of the element. Below is a descriptionof the specific requirements for each data model element.
(1) characterstring
A string of characters defined in ISO 10646, which is equivalent to the Unicode
standard.
(2) localized string typeA character string that contains a character string indicating the language of thecharacterstring. SCORM uses a reserved delimiter to represent the language fora character string: {lang=<language_type>}. Whether to specify thislocalized string type is optional. If it is not specified, the default language is en,
which means English as in {lang=en}. The syntax for specifying this data
type element is as follows:“{lang=<language_type>}<actual_character_string>”
Example:{lang=ja}鈴木 一郎

61

SCORM 2004 Content Development Guide(3) language typeThe data type used to represent the language. The format of this data typeelement is a character string consisting of a language code (langcode) followedby zero or more hyphen-prefixed subcodes (subcode).
language_type ::=langcode [“-“subcode]*
Example:ja en-GB(4) long identifier typeThis data type element represents a label or identifier. This label or identifiermust be unique within the context of an SCO. It must conform to the syntax
defined for the universal resource identifier (URI). SCORM recommends that the
URI be a globally unique identifier in the form of a uniform resource name
(URN). The values of this long identifier type element should be implemented
with an SPM of 4000 characters.
<URN>::=”urn.”<NID>”.”<NSS>
where <NID> is a name space identifier and <NSS> is a namespace string.
Example:urn:ADL:interaction-id-0001(5) short identifier typeThis label or identifier must be unique within the context of an SCO. This data
type element must conform to the syntax defined for the URI. It is not assumed
that the values of this data type element are globally unique identifiers. The
values should be implemented with an SPM of 250 characters.
(6) integer
This data type element is a member of a set of positive whole numbers (e.g., 1, 2,3), negative whole numbers (e.g., -1, -2, -3) and zero (0).
(7) state
Some of the data model elements values have a defined set of states. This isdefined by a statement like the following:
Example:state (browse,normal,review)(8) real(10,7)This data type element refers to a real number with seven significant digit
precision.
(9) time(second, 10, 0)This time data type has a required precision of 1 second and an optional
precision of 0.01 second.
Example:2003-07-25T03:00:00(10)

timeinterval(second, 10,2)
The value for this data type element represents a period of elapsed time with a
precision of 0.01 second.
Example:P1Y3M2DT3H
which means 1 year, 3 months, 2 days and 3 hours.

62

SCORM 2004 Content Development Guide
5.4.2.8 SCORM Run-Time Environment Data Model Extension
The SCORM Run-Time Environment Data Model is expected to be implemented
without extension. If an LMS receives an API request with an undefined data model
element, the LMS should handle it as an error.

5.4.3 SCORM Run-Time Environment Data Model
5.4.3.1 Data Model Overview
The SCORM Run-Time Environment Data Model contains a set of data that can betracked by an SCO on the LMS during the run-time of the SCO. These data model
elements are used to track items such as status, scores, interactions, and objectives.
Some data model elements are used to exchange data between the SCO and the LMS,
while others may be used to affect the sequencing process for other SCOs that areassociated within the activity tree. Table 5.8 summarizes the data model elements.
Table 5.8 List of SCORM Run-Time Environment Data Model Elements
No Data Model Element
Description
1
Contains text from the learnercmi.comments_from_learner
2
Contains comments and annotations to
cmi.comments_from_lms
be provided for the learner
3
Indicates whether the learner has
cmi.completion_statuscompleted the SCO
4
Indicates a value against which the
cmi.completion_thresholdlearner’s measure of progress is to becompared to determine whether thelearner has completed the SCO
5
Indicates whether the learner’s
cmi.credit
performance with the SCO is to becredited
6
Contains information indicating whether
cmi.entry
the learner has accessed the SCO before
7
Contains information as to why andcmi.exit
how the learner exited from the SCO
8Defines information concerning an
cmi.interactions
interaction for the purpose ofmeasurement or assessment
9
Provides data specific to an SCO thatcmi.launch_data
the SCO can use for initialization
10 cmi.learner_id
Identifies the learner for whom the SCO
instance was launched
11 cmi.learner_name
Represents the name of the learner
12 cmi.learner_preference
Specifies learner preferences associatedwith the learner’s use of the SCO
13 cmi.location
Represents a location in the SCO. Itsvalue and meaning are determined by
the SCO.

63

SCORM 2004 Content Development Guide
No Data Model Element
14 cmi.max_time_allowed
15

cmi.mode

16

cmi.objectives

17

cmi.progress_measure18

cmi.scaled_passing_score19

cmi.score

20

cmi.session_time

21

cmi.success_status

22

cmi.suspend_data

23

cmi.time_limit_action

24

cmi.total_time

Description
Indicates the accumulated amount oftime that the learner is allowed to use
for an SCO in the learner attempt
Identifies the modes in which the SCO
may be presented to the learnerSpecifies learning objectives associatedwith an SCO
Identifies a measure of the progress thelearner has made toward completing the
SCO
Identifies the scaled passing score for an
SCO
Identifies the learner’s score for the
SCO
Identifies the amount of time that thelearner has spent in the current session
for the SCO
Indicates whether the learner has
mastered the SCO
Provides additional space for storing
and retrieving information relating to
the suspension of an SCO
Indicates what the SCO should do whenthe maximum time allowed is exceeded
Provides the sum of all of the learner’s
session times accumulated in thelearner’s current attempt64

SCORM 2004 Content Development Guide

5.4.3.2 Details of the Data Model Elements
Table 5.9 SCORM RTE Data Model Elements – DetailNo

Data Model Element

Data Type

Value Space0.1

cmi._version

characterstring

ISO-10646-1

1.

cmi.comments_from_learner

1.0.1
1.0.2

cmi.comments_from_learner._children
cmi.comments_from_learner._count

1.1

cmi.comments_from_learner.n.comment

1.2

cmi.comments_from_learner.n.location

1.3

cmi.comments_from_learner.n.timestamp2.

cmi.comments_from_lms

2.0.1
2.0.2

cmi.comments_from_lms._children
cmi.comments_from_lms._count

2.1

cmi.comments_from_lms.n.comment

2.2

cmi.comments_from_lms.n.location

2.3

cmi.comments_from_lms.n.timestamp3.

cmi.completion_statuscollection
SPM: 250
characterstring
integer
localized_
string_type
SPM: 4000
characterstring
SPM: 250
time(second,10,0)
collection
SPM: 100
characterstring
integer
localized_
string_type
SPM: 4000
characterstring
SPM: 250
time(second,10,0)
state

SCO

Remarks

R

Delimited by aperiod
“1.0”−
ISO-10646-1
Non-negative
integer
Localized string
type(ISO-10646-1)
ISO-10646-1

RR
Not initialized
R/W
R/W
R/W
−

ISO-10646-1
Non-negative
integer
Localized string
type(ISO-10646-1)
ISO-10646-1

R
R
R
R
R
Default:“unknown”“complete”“incomplete”“not_attempted”“unknown”
R/W4.

cmi.completion_thresholdreal(10,7)
range (0..1)

R

It is assumed
that an SCO is to
set the value of
this element, andthat it affects
sequencing．
LMS determines
the completion
status bycomparing the「17.
cmi.progress_measure」
against thevalue.
The result of thishas a higher
priority than
「3.
cmi .completion_status」 which
is set by an
SCO. This isinitialized with avalue defined for<adlcp:completi
onThreshold> inthe manifest file.

* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

65

SCORM 2004 Content Development Guide

No

Data Model Element

Data Type

Value Space5.

cmi.credit

state

6.

cmi.entrystate“credit”“no_credit”“ab_initio”“resume”“”(Empty
string)“time-out”“suspend”“logout”“normal”“”(Empty
string)7.

8.

cmi.exit

state

cmi.interactions

collection

8.0.1
8.0.2

cmi.interactions._children
cmi.interactions._count

SPM: 250
characterstring
integer

8.1

cmi.interactions.n.id

SCO

RemarksR

Default:“credit”

RW−

long_identifier_typeISO-10646-1
Non-negative
integer
URI (RFC
2396)-compliant
character string

SPM: 4000

8.2

cmi.interactions.n.type

8.3

cmi.interactions.n.objectives

8.3.0.1

cmi.interactions.n.objectives._count

8.3.1

cmi.interactions.n.objectives.n.id

statecollection
SPM: 10integer
long_identifier_type)
SPM: 4000

R
R

R/W
URN (RFC
2141)
Recommended“true-false”“choice”“fill-in”“long-fill-in”“likert”“matching”“performance”“sequencing”“numeric”“other”

R/W

Must be unique
within thecontext of an
SCO.

The
correct_response
andlearner_response
elements are
dependent on
this data model
element, and thismust be set
before these two
dependent
elements areused.

−
Non-negative
integer 0
URI (RFC
2396)-compliant
character string

R

R/W
URN (RFC
2141)
Recommended
8.4

cmi.interactions.n.timestamp

8.5

cmi.interactions.n.correct_responses

Time(second,10,0)
collection

R/W−

8.5.0.1

cmi.interactions.n.correct_responses._count

SPM: 10integer

Non-negative
integerR* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

66

SCORM 2004 Content Development Guide

No

Data Model Element

Data Type

8.5.1

cmi.interactions.n.correct_responses.n.
pattern

Dependent on
8.2
cmi.
interactions.n.
type
real (10,7)

8.6
8.7

8.8

8.9
8.10
9.

cmi.interactions.n.weighting

cmi.interactions.n.learner_
response

cmi.interactions.n.result

cmi.interactions.n.latency

cmi.interactions.n.description

cmi.launch_data

Dependent on
8.2
cmi.
interactions.n.
type
state

Value SpaceReal with 7
significant
decimal digits

cmi.learner_id

R/W

R/W

“correct”“incorrect”“unanticipated”“neutral”
real(10,7)

R/W

R/W
Localized string
type

R/W

ISO-10646-1

SPM: 4000

10.

Remarks

R/Wtimeinterval(second,10,2)
Localized_string_type
SPM: 250
characterstring

SCO

R

long_identifier_type
SPM: 4000

URI (RFC
2396)-compliant
character string

localized_string_type

URN (RFC
2141)
Recommended
Localized stringtype

Initialized by thewith a value
defined for<adlcp:dataFrom
LMS> in the
manifest file.
Provided by the
LMS

R

11.

cmi.learner_name

R

Provided by the
LMS

SPM: 250
12..
12.0.
1
12.1

12.2

cmi.learner_preference
cmi.learner_preference._children
cmi.learner_preference.audio_level

characterstring

ISO-10646-1

real(10,7)，
range (0..*)A real number
with 7significant
decimal digits
ISO-646

cmi.learner_preference.language

language_type

cmi.learner_preference.delivery_speed

SPM: 250
real(10,7)，
range (0..*)

R
R/W

R/W
12.3

12.4

cmi.learner_preference.audio_captioningstate

A real number
with 7significant
decimal digits
“-1”
“0”
“1”

R/W

R/W

Corresponding
tokens:“off”“no_change”“on”* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

67

SCORM 2004 Content Development Guide

No

Data Model Element

Data Type

Value Space13.

cmi.location

characterstring

ISO-10646-1

SCO

SPM: 1000
R/W

14.

15.

cmi.max_time_allowed

cmi.mode

timeinterval(second,10,2)
With
resolution to
0.01 second.
state

R

“browse”“normal”“review”
R

16.

cmi.objectives

collection

16.0.1
16.0.2

cmi.objectives._children
cmi.objectives._count

SPM: 100
characterstring
integer

16.1

cmi.objectives.n.id

Remarks
The initial value
is“”（Empty
string）
An LMS should
not update orinterpret thisvalue. This canbe used to savethe SCO’s exit
point.
Initialized with avalue defined for<imsss:attemptAbsoluteDurationLimit> in the
manifest file.
Default:“normal”
Related with：「5.
cmi.credit」−

long_identifier_typeISO-10646-1
Non-negative
integer
URI (RFC
2396)-compliant
character string

R
R
Must be uniqueat least within
the context of an
SCO.

SPM: 4000
URN (RFC
2141)
Recommended

16.2
16.2.0.
1
16.2.116.2.2

cmi.objectives.n.score
cmi.objectives.n.score._children
cmi.objectives.n.score.scaled

cmi.objectives.n.score.raw

R/W

Initialized withthe value definedas the identifierfor<imsss:object
tives>
in the manifest
file.

−characterstring

ISO-10646-1

real (10,7)
range (-1..1)

Real number
with 7significant
decimal digits
within the range
between -1.0 and
1.0Real number
with 7significant
decimal digits

real (10,7)

R

R/W

The data model
element affects
the objective
measure for theactivity
associated with
the SCO.

R/W* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

68

SCORM 2004 Content Development Guide

No

Data Model Element

Data Type

Value Space16.2.3

cmi.objectives.n.score.min

real (10,7)

Real number
with 7significant
decimal digits
Real number
with 7significant
decimal digits“passed”“failed”“unknown”

16.2.416.2.5

cmi.objectives.n.score.max

cmi.objectives.n.success_statusreal (10,7)

state

SCO
R/W

R/W

R/W

16.2.616.2.716.2.817.

cmi.objectives.n.completion_status

cmi.objectives.n.progress_measure

cmi.objectives.n.description

cmi.progress_measurestate

real (10,7)
range (0..1)

Localized_string_type
SPM: 250
real (10,7)
range (0..1)“completed”“incomplete”“not_attempted”“unknown”
Real number
with 7significant
decimal digits
within the range
between 0 and
1.0.
Localized string
type(ISO-10646-1)

cmi.scaled_passing_score19.

cmi.score

19.0.1

cmi.score._children

real (10,7)
range (-1..1)

R/W

R/W

Real number
with 7significant
decimal digits
within the range
between 0 and
1.0Real number
with 7significant
decimal digits
within the range
between -1.0 and
1.0Rcharacterstring

ISO-10646-1

The data model
element affects
the Objective
Progress Status
for the activity
associated with
the SCO.

R/W

R/W

18.

Remarks

Mapped with thevalue of 「3.
cmi.completion_status」
0⇒“not attempted”
1⇒“completed”
0 > value < 1 ⇒“incomplete”
Note) Thisapplies when
there is no
definedthreshold value.
Initialized withthe value definedfor<imsss:minNor
malizedMeasure> inthe manifest file.
Mainly used by
SCOs

R* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

69

SCORM 2004 Content Development Guide

No

Data Model Element

Data Type

Value Space

19.1

cmi.score.scaled

real (10,7)
range (-1..1)

Real number
with 7significant
decimal digits
within the range
between -1.0 and
1.0

19.2

19.3

19.4

20.

21.

cmi.score.raw

cmi.score.max

cmi.score.min

cmi.session_time

cmi.success_statusreal (10,7)

real (10,7)

real (10,7)

Real number
with 7significant
decimal digits
Real number
with 7significant
decimal digits
Real number
with 7significant
decimal digits

SCO

Remarks

R/W

The value of thisdata model
element must be
synchronizedwith the initialvalue of the
Objective
Measure Status
for the SCO．

R/W

R/W

R/W

timeinterval(second,10,2)
With
resolution to
0.01 second
state

W

Initialized by the
SCO“passed”“failed”“unknown”

The LMS cannot
directly change
this data model
element, but it
can indirectly
change the value
by setting avalue to 「18.
cmi.scaled_passing_score」
R/W（In this case,the LMS canoverride thevalue of the data
model element
reported by the
SCO.）
This data model
element must be
synchronizedwith the initial
Objective
Measure Statusvalue for the
SCO．

* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

70

SCORM 2004 Content Development Guide

No

Data Model Element

Data Type

Value Space22.

cmi.suspend_data

characterstring

ISO-10646-1

SCO

SPM: 4000

R/W

23.

24.

cmi.time_limit_action

cmi.total_time

state“exit,message”“continue,
message”“exit,nomessage”“continue,
no message”

Rtimeinterval(second,10,2)
With
resolution to
0.01 second

R

Remarks
The LMS should
not attempt tointerpret orchange this data,
which is meant
to be used by the
SCO for current
or subsequentsessions.
Related to：「13.
cmi.location」
Initialized withthe value definedfor<adlcp:timeLim
itAction> in the
manifest file.
Default:“continue,nomessage”
The LMS cannot
determine thelatest value forthis data element
until the SCO
sets session timevalues to the
cmi.session_
time element.

* Notes on the SCO column: R: Read-only, W: Write-only, R/W: Read and Write

71

SCORM 2004 Content Development Guide

6 Features of SCORM 2004 Content
This section explains how to represent the characteristic behaviors of SCORM 2004
content by using actual examples to make it to easy to understand the correspondence
between behavior and code. It also explains, using examples, how educational
concepts like completion and objectives are represented in the SCORM 2004 standard.

6.1 Sequencing Features
This subsection describes the features of sequencing, added as a main function in
SCORM 2004, and explains how to encode sequencing strategies.

6.1.1 Specifying Sequencing Strategies
The content developer controls the behavior of content by describing content
structures and their associated behavior rules (sequencing rules) in the manifest file(imsmanifest.xml). The majority of sequencing rules are specified in cluster units, andthe rules specified with the root of a cluster are applied to the entire cluster.
In addition, tracking information used in the application of sequencing rules is
associated with each individual activity. The tracking information for a cluster, whichis the tracking information for a parent activity, is rolled up from the data for its child
activities. How the parent activity’s data should be rolled up is specified by thecontent developer using a set of rollup rules.
Sequencing
シーケンシン
Rule
ルー

Rollup

1.

ロールアッ
Rule
ルー

1.1
Cluster
1.1.1

Objective

1.1.2

1.3

1.2

1.1.3

1.2.1

(Reflecting tracking
information on parent
i i )
1.2.2

Determining content behavior withsequencing rules

Figure 6.1 Content Behavior Control through Sequencing Rules

6.1.2 Specifying Sequencing Control Modes(1) Overview
Sequencing control modes control the sequencing behavior for a cluster, and thesecontrol modes are used to specify the degree of freedom allowed for the learner toselect SCOs and decide upon a navigation path.
The sequencing control modes can be specified for each cluster, and the specified
control modes are applied to the cluster’s child activities. For example, a control
72

SCORM 2004 Content Development Guide
mode specification may be [The activities in this cluster should be presented in theforward direction only and backward movement is not allowed.](2) Specification Method
Specify the <imsss:controlMode> element in the manifest file for each cluster.
(3) Description of Each Attribute
a. Sequencing Control ChoiceThis sequencing control mode is used to specify whether the learner will beallowed to choose a candidate activity to attempt from the menu. If the value isTrue, then the learner is allowed to choose any activity within the cluster. The
default value is True.
Control Mode
Choice= TrueChoice Exit = True

Flow

1.

= TrueForward Only = False

1.1

1.2

1.3

The learner is free to choose.
Figure 6.2 Sequencing Control Choiceb. Sequencing Control Choice Exit
This sequencing control mode is used to specify whether a Choice sequencing
request can be used to move from the current activity or any of its descendantactivities to another activity outside of the current activity’s control. The default
value is True.
c. Sequencing Control Flow
This sequencing control mode is used to specify whether to allow movement fromone activity to another within the cluster in a forward or backward direction usinga Continue sequencing request or a Previous sequencing request. The default is
True.

73

SCORM 2004 Content Development Guide
Control Mode
Choice= False
Choice Exit = True
Flow
= True1.

Forward Only = False

1.1

1.2

Continue

Continue

1.3

Previous

Previous

The learner is free to move.
Figure 6.3 Sequencing Control Flowd. Sequencing Control Forward Only
This sequencing control mode is used to specify whether to allow only forward
movement among the activities in a cluster without allowing backward movement.
If the value is True, the learner is allowed to move in the forward direction only,with a Continue sequencing request or a Choice sequencing request in the forward
direction.
Control Mode
Choice= False
Choice Exit = True
Flow
= True1.

Forward Only = True

1.1

1.2

Continue

ContinuePrevious

1.3

Previous

The learner cannot move backward.
Figure 6.4 Sequencing Control Forward Onlye. Use Current Attempt Objective Information
This sequencing control mode is used to specify whether the objective informationfrom the current attempt on a child activity only is used in the rule evaluation forthe cluster as tracking information regarding its child activities. The default isTrue. If the value is False, the latest information, including the most recent
previous attempt on a child activity, is used for the rule evaluation.

74

SCORM 2004 Content Development Guide

f. Use Current Attempt Progress Information
This sequencing control mode is used to specify whether the progress informationfrom the current attempt on a child activity only is used in the rule evaluation forthe cluster as the tracking information regarding its child activities. The default isTrue. If the value is False, the latest information, including the most recent
previous attempt on a child activity, is used for the rule evaluation.
(4) Coding Example<item identifier="PRETEST1"><title>A Pretest</title><item identifier="Q1" isvisible = "false" identifierref=" RQ1"><title>Question1</title></item><item identifier="Q2" isvisible = "false" identifierref=" RQ2"><title>Question2</title></item><item identifier="Q3" isvisible = "false" identifierref=" RQ3"><title>Question3</title></item><imsss:sequencing><imsss:controlMode choice="false" choiceExit="false"
flow="true" forwardOnly = "true"/></imsss:sequencing></item>(5) Note for Implementation• The Sequencing Control Flow should be set to True when the Sequencing
Control Choice is True.
Reason: Otherwise, unless the learner specifically selects an activity, nothing
will be displayed.
• It will help learner understanding if the specification for the first activity of acluster contains an indication that its child activities (SCOs) can be freely
selected.
• The Sequencing Control Forward Only has priority to the Sequencing Control
Flow.

6.1.3 Specifying Sequencing Rules
6.1.3.1 Sequencing Rules(1) Overview
Sequencing rules are used to determine the sequence of learning experiences based on
tracking information (objective status). For example, it is possible to specify the
behavior of content as follows:• If a particular learning objective is satisfied, then this activity is to be skipped.
• If a post-test score does not exceed 70 points, the post-test is repeated up to
three times.
Condition rules are described on the basis of the if – then structure. If the tracking
information satisfies a given condition, a constraint is placed on content behavior suchas the issuing of a sequencing request or the learner’s navigation between activities.
75

SCORM 2004 Content Development Guide(2) Specification Method
Specify the <imsss:sequencingRules> element in the manifest file for each activity.
(3) Component Element Specificationa. Sequencing rules
Sequencing rules are defined using the if – then rule structure.
If [condition_set] Then [action]
There are three rule conditions depending on when the rules are applied if they
are satisfied:• Precondition rules: Rules that are applied prior to the delivery of theassociated activity.
• Postcondition rules: Rules that are applied when the associated activity has
ended.
• Exit rules: Rules that are applied when a descendent activity has ended.
b. Condition set
The condition set describes a set of conditions that need to be satisfied for the
execution of the action part. The condition set is a logical expression that isevaluated as True or False depending on the values of tracking information
elements such as the objective measure and the progress status for the activity.
A condition set may contain multiple conditions.
A condition combination indicates how the component conditions are to be
combined in an evaluation. The All condition combination indicates that theresult of all the component conditions must be True for the condition set to beevaluated as True, and the Any condition combination indicates that any one of
the component conditions must be evaluated as True for the condition set to beevaluated as True. The default condition combination is Any.
• all: Set to True if all conditions are True.
• any: Set to True if any condition is True.
A condition set and a condition combination are specified in the<imsss:ruleConditions> element.
A condition operator is a unary logical operator applied after the evaluation of
the rule condition.
• noOp: The Boolean value of the associated condition is not changed and isused as is in the rule evaluation.
• not: The associated condition is negated in the rule evaluation.
The default condition operator is noOp.
The condition elements represent elements whose values are set to True orFalse depending on the tracking information for the activity. Condition
elements and condition operators are specified in the <imsss:RuleCondition>
element.

76

SCORM 2004 Content Development Guidec. Action
The action part determines the activity to be delivered next. It may also be
used to issue a new sequencing request or termination request. The action tobe performed differs depending on the sequencing condition applied. Only one
action can be specified for a sequencing rule <imsss:ruleAction>.
•••

Precondition actions:o “Skip”, “Disabled”, “Hidden from Choice”,“Stop Forward Traversal”
Post-condition actions:o “Exit Parent”, “Exit All”, “Retry”, “Retry All”, “Continue”“Previous”
Exit actions:o “Exit”
Sequencing Rule: If [condition_set] Then [action]
Condition Set: If (All/Any) [condition_set]
Condition: (not) [condition]
Condition
Combination

Condition
Operator

Condition
Element(All/Any

Action: Then [action]

Figure 6.5 Sequencing Rule Description(4) Coding Example
The coding example below shows how to describe a sequencing rule, If “notsatisfied” Then “retry”.

77

SCORM 2004 Content Development Guide<item identifier="DRILL1"><title>Drill</title><item identifier="Q1" isvisible = "false" identifierref="RQ1"><title>Question 1</title></item><item identifier="Q2" isvisible = "false" identifierref="RQ2"><title>Question 2</title></item><imsss:sequencing><imsss:sequencingRules ><imsss:postConditionRule><imsss:ruleConditions><imsss:ruleCondition operator = “not”
condition = "satisfied"/></imsss:ruleConditions><imsss:ruleAction action = "retry"/></imsss:postConditionRule></imsss:sequencingRules></imsss:sequencing></item>(5) Note for Implementation
If the tracking information to be captured is information regarding the Objective
Satisfied Status and the Objective Normalized Measure, it is necessary to specify thetarget objective for the Rule Condition Referenced Objective, and to specify athreshold value for the Rule Condition Measure Threshold against which the
Objective Normalized Measure is compared.
6.1.3.2 Specifying Precondition Rulesa. Sequencing Rule Description
Precondition rules are defined using the <preConditionRule> element.
b. Condition_set
The condition elements that can be used in a condition set are shown in Table 6.1.
Table 6.1 Condition Elements for Precondition Rules
Condition Element Tracking Information
Description
SatisfiedObjective Satisfied Status Evaluated as True if the Objective
Satisfied Status is “satisfied”
Objective Status
Objective Satisfied Status Evaluated as True unless the
Objective Satisfied Status isKnown“unknown”
Evaluated as True if the Objective
Objective Measure Objective Normalized
Normalized Measure is greater
Greater Than
Measurethan the specified threshold value
Evaluated as True if the Objective
Objective Measure Objective Normalized
Normalized Measure is less thanLess Than
Measurethe specified threshold value
Evaluated as True if the Attempt
Completed
Attempt Completion
Completion Status is “completed”
Status78

SCORM 2004 Content Development Guide
Condition Element
Activity Progress
Known

Tracking Information
Attempt Completion
StatusAttempted

Activity Attempt Count

Attempt Limit
Exceeded

Activity Attempt Count

AlwaysNone

Description
Evaluated as True unless the
Attempt Completion Status is“unknown”
Evaluated as True if the Activity
Attempt Count is 1 or more
Evaluated as True if the Activity
Attempt Count is greater than thevalue specified in the limit
condition
Always evaluated as Truec. Action
One of the actions shown in Table 6.2 is used for the action part of a precondition
rule.
Table 6.2 List of Actions Used in Precondition Rules
ActionDescription
This action is used when the candidate activity to be
Skip
delivered next is determined by traversing the activity treewith a Continue or a Previous sequencing request.
This action is used to disable the activity to be delivered.
Disabled
This action is used to stop the activity from being
Hidden From Choicepresented by a Choice sequencing request.
Stop Forward Traversal This action is used when the candidate activity to bedelivered next is determined by traversing the activity tree
in the forward direction.
6.1.3.3 Specifying Postcondition Rulesa. Sequencing Rule Description
Postcondition rules are defined using the <postConditionRule> element.
b. Condition Set
The condition elements that can be used in a condition set are the same as thoseshown above for the precondition rules.
c. Action
One of the actions shown in Table 6.3 is used for the action part of a postcondition rule.
ActionExit Parent
Exit All
Retry

Table 6.3 List of Actions Used in Postcondition Rules
Description
This action is used to end the parent activity
This action is used to end the entire activity tree
This action is used to specify that the current activity is tobe retried. If the associated activity is not a leaf activity,
the cluster is retried from its first activity.

79

SCORM 2004 Content Development Guide
ActionRetry All

Description
This action is used to specify that the entire activity tree isto be terminated and then retriedMove forward
Move backward

ContinuePrevious

6.1.3.4 Specifying an Exit Rulea. Sequencing Rule Description
An exit rule is defined using the <exitConditionRule> element.
b. Condition Set
The condition elements that can be used in a condition set are the same as thoseshown above for the precondition rules.
c. Action
The action shown below is used for the action part of an exit condition rule.
Table 6.4 Action Used in an Exit Rule
Description
This action is used to end the activity

ActionExit

6.1.4 Specifying Rollup Rules(1) Overview
The tracking information is derived from leaf activities. To derive or update thetracking information for each cluster or the entire activity tree, it is necessary to rollup the tracking information of the associated child activities to the parent activities. A
mechanism for implementing this process is called rollup, and the rules applied to thisprocess are called rollup rules.
Rollup1.

Rollup Rules

Rolling up
tracking
information

OK

1.1

1.2
OK

SCO

1.3
OK

OK

1.2.1

1.2.2

1.2.3

1.3.1

1.3.2
Capturing
tracking

SCO

SCO

SCO

SCO

SCO

OK: Completed

80

SCORM 2004 Content Development Guide
Figure 6.6 Rollup Rules
There are three types of rollup rule that can be defined: those for the objective
satisfied status, those for the objective normalized measure and those for the attempt
completion status.
(2) Specification Method
Specify the <imsss:rollupRules> element in the manifest file for each cluster.
(3) Component Element Specificationa. Rollup Rules
Rollup rules are defined using the following rule structure.
If [condition_set] For [child activity set] Then [action]
A rollup rule consists of a child activity set, a set of conditions (the condition set)
to be evaluated for each activity included in the child activity set, and the actionthat sets the tracking information for the cluster if the rollup conditions are met.
b. Condition Set
A condition set describes a set of conditions that need to be satisfied for the
execution of the action part. The condition set is a logical expression that isevaluated as True or False depending on the values of tracking information
elements such as the objective measure and the progress status for the activity. A
condition set may contain multiple conditions.
A condition combination indicates how the component conditions are to be
combined in evaluation. The All condition combination indicates that the result of
all the component conditions must be True for the condition set to be evaluated as
True, and the Any condition combination indicates that any one of the component
conditions must be evaluated as True for the condition set to be evaluated as True.
The default condition combination is Any.
• all: Set to True if all conditions are True.
• any: Set to True if any condition is True.
A condition set and a condition combination are specified in the<imsss:ruleConditions> element.
A condition operator is a unary logical operator that is applied after the evaluationof the rule condition.
• noOp: The boolean value of the associated condition is not changed and isused as is in rule evaluation.
• not: The associated condition is negated in the rule evaluation.
The default condition operator is noOp.
The condition elements represent the elements whose values are set to True orFalse depending on the tracking information for the activity. Condition elements
and condition operators are specified in the <imsss:rollupCondition> element.

81

SCORM 2004 Content Development Guide
The condition elements that can be used in a condition set are shown in Table 6.5.
Table 6.5 Condition Elements for Rollup Rules
Condition Element Tracking Information
Description
SatisfiedObjective Satisfied Status Evaluated as True if the Rollup
Objective Satisfied Status is“satisfied”
Objective Status
Objective Satisfied Status Evaluated as True unless the
Rollup Objective Satisfied Status isKnown“unknown”
Evaluated as True if the Rollup
Objective Measure Objective Normalized
Objective Normalized Measure is
Known
Measurenot “unknown”
Evaluated as True if the Attempt
Completed
Attempt Completion
Completion Status is “completed”
Status
Evaluated as True unless theActivity Progress
Attempt Completion
Attempt Completion Status is
Known
Status“unknown”
Evaluated as True if the Activity
Attempted
Activity Attempt Count
Attempt Count is 1 or more
Evaluated as True if the Activity
Attempt Limit
Activity Attempt Count
Attempt Count is greater than the
Exceededvalue specified in the limit
condition
None
Always evaluated as False
Neverc. Child Activity Set
A child activity set is used to define how the results of applying the specified
conditions to each child activity included in the child activity set are used todetermine whether the final evaluation result should be set to True or False. For
example, a child activity set can be used to define a situation as follows: if 80% of
the child activities satisfy the specified condition set after the condition set has
been applied to each child activity, the final evaluation result becomes True.
Table 6.6 List of Child Activity Sets
Description
If the result for all child activities is True, the final
All
result is considered True
If the result for any child activity is True, the final
Any
result is considered True
If none of the child activities satisfies the condition,None
the final result is considered True
If the result for at least the specified number of child
At Least Count
activities is True, the final result is considered True
If the result for at least the specified percent of child
At Least Percent
activities is True, the final result is considered True
Name

When At Least Count is specified, a minimum number of activities must be
specified using the minimumCount attribute.

82

SCORM 2004 Content Development Guide
When At Least Percent is specified, a number to indicate the minimum percentage
value must be specified using the minimumPercent attribute.
The child activity set is defined in the <imsss:rollupRule> element.
d. Action
If the specified rollup rules are evaluated as True, the status information of theparent is updated.
ActionSatisfied
Not Satisfied
Completed
Incomplete

Table 6.7 List of Actions Used in Rollup Rules
Description
The Objective Satisfied Status value for the parent is set to“satisfied”
The Objective Satisfied Status value for the parent is set to“not satisfied”
The Attempt Completion Status value for the parent is set
to “completed”
The Attempt Completion Status value for the parent is set
to “incomplete”

Rollup Rule: If [condition_set] Then [action] For [child_activity_set]
Condition Set: If (All/Any) [condition_set](All/Any/None/….)Condition
Operatorchild_activity

Condition
Element

(All
/Any)

Child activity set

Condition
Combination

Condition: (not) [condition]

child_activity

child_activity

child_activity
Action: Then [action]

Figure 6.7 Rollup Rule Description(4) Coding Example
The coding example below shows how to describe a rollup rule, If “attempted” For“All” Then “completed”, which means that if all the child activities have been
attempted the parent activity is regarded as completed.

83

SCORM 2004 Content Development Guide<item identifier="SCORM1"><title>SCORM Handbook</title><item identifier=" CHAPTER1"><title>SCORM Overview</title><item identifier="C1" isvisible = "true"
identifierref="RC1"><title>What is SCORM?</title></item><item identifier="C2" isvisible = "true"
identifierref="RC2"><title>History of SCORM</title></item><item identifier="C3" isvisible = "true"
identifierref="RC3"><title>SCORM Basics</title></item><imsss:sequencing><imsss:rollupRules ><imsss:rollupRule childActivitySet = "all"><imsss:rollupConditions><imsss:rollupCondition
condition = "attempted"/></imsss:rollupConditions><imsss:rollupAction action = "completed"/></imsss:rollupRule></imsss:rollupRules></imsss:sequencing></item></item>(5) Note for Implementation
A child activity set that is subject to a rollup rule generally includes all the child
activities in the cluster, but some child activities are not included in the rollup rule
application as follows:••••

Activities for which the Tracked element of the deliveryControls element isdefined as False. As no tracking information is derived for these activities, they
do not contribute to the rollup of their parents.
Activities for which the Rollup Objective Satisfied element is defined as False.
These activities are not subject to rollup rules which have the Satisfied or Not
satisfied action.
Activities for which the Rollup Progress Completion element is defined as False.
These activities are not subject to rollup rules which have the Completed or
Incomplete action.
Activities that do not satisfy the condition specified in the Required For elementof the parent activity definition. These activities are not considered in the rollupof their parents.

84

SCORM 2004 Content Development Guide

Rollup Rules
Request For Completed = False
Not Contributing to Rollup.
OK

Delivery Controls
Tracked = False

1

1.1

OK

OK

OK

1.2

1.3
OK: Completed

Rollup Rules
Rollup Objectives Satisfied = False
Rollup Progress Completion = False

Figure 6.8 Rollup

6.1.5 Specifying Limit Conditions(1) Overview
Limit conditions can be defined that describe conditions under which delivery of anactivity is not allowed. In the current standard, for example, the number of attempts
can be limited. If the Limit Condition Attempt Limit element is defined for an activity,
the learner is not allowed to attempt that activity for more than the specified limit
value.
(2) Specification Method
Specify the <imsss:limitConditions> element in the manifest file for each cluster.
(3) Description of Parameters
a. Attempt Limit
The attemptLimit attribute is used to assign a limit on the number of allowed
attempts for each activity. The default value is 0. If the attempt limit value of anactivity is 0, that activity is not accessible.
b. Attempt Absolute Duration Limit
This attribute is used to limit the maximum amount of time allowed for an activity.
However, SCORM does not specify the behavior of the LMS and SCOs for thislimit definition. The only requirement for the LMS is that it should implement the
cmi.max_time_allowed element of the RTE data model, and initialize its value
with the value specified in this attribute. (It is the responsibility of the SCO to givethe actual allowed time limit.)
The limit value is specified with a numeric value in theattemptAbsoluteDurationLimit attribute, and the default value is 0.0.
85SCORM 2004 Content Development Guide

1.1
Limit ConditionsattemptAbsoluteDurationLimit= 60.0

1.1.1

SCO

1.1.2
1.1.3

Manifest file

SCO
Data Model
SCO

GetValue(“cmi.max_time_allowed”)
Î 60.0 (Initial value)

Figure 6.9 Limit Condition Description(4) Coding Examples
Example 1: Limit the attempt count to 1.
<item identifier="INTRO" identifierref="RINTRO"><title>A Course Outline</title><imsss:sequencing><imsss:limitConditions attemptLimit="1"/></imsss:sequencing></item>Example2: Limit the amount of time allowed for one attempt to 2 minutes.
<item identifier="POST" identifierref="RPOST"><title>A Course on SCORM2004</title><imsss:sequencing><imsss:limitConditions attemptAbsoluteDurationLimit ="120.0"/></imsss:sequencing></item>6.1.6 Specifying Objectives
At least one objective should be assigned to each activity. A content developer may
assign any number of additional objectives to the activity as required. The scope ofthese objectives is local to the activity for which they are defined and they are local
objectives. However, shared global objectives can be defined in association with local
objectives. These global objectives can be shared by activities for sequencing. For
example, a pretest activity and a tutorial activity may have a shared global objective
to make it possible to determine whether the tutorial activity is to be delivered
depending on the result of the pretest activity.
The main points concerning objective descriptions can be summarized as follows:(1) More than one objective can be defined for one activity.
86

SCORM 2004 Content Development Guide(2) In principle, objectives are local to the activity for which they are defined.
(3) Other activities can refer to an activity’s objective information by defining ashared global objective.
1.

An activity may havemore than one objective
1.1

1.3

1.2
Objective

Objective
学習目
Write

Read

SharedGlobal学習目
Objective
Objective information canbe referred to fromother activities

Objective progress information
can only be available to theactivity for which it is defined.

Figure 6.10 Objective Description
6.1.6.1 Objectives(1) Overview
An activity has one local objective by default. However, a content developer may
assign any number of local objectives for an activity as required.
(2) Specification Method
Objectives are defined by using the <imsss:objectives> element for each activity inthe manifest file. The default objective is defined by using <imsss:primaryObjective>
and additional objectives are defined by using <imsss:objective>.
(3) Description of Parameters
a. Objective ID
This attribute defines an identifier of an objective associated with an activity. Itshould be unique within the scope where the objective is referred to.
b. Objective Satisfied by MeasureThis attribute indicates whether the satisfied status of the objective should bedetermined by the Minimum Normalized Measure for the Objective. The value isdescribed with a boolean value: “true” or “false”. The default value is “false”.
c. Objective Minimum Satisfied Normalized MeasureThis element indicates the minimum satisfaction measure for the objective. Thisvalue is used as the threshold value against which the objective’s normalizedmeasure is evaluated. The measure is defined with a normalized value between -1
and 1. The default value is 1.0.
87

SCORM 2004 Content Development Guide

d. Objective Contributes to Rollup5This attribute indicates whether the objective contributes to the rollup of its parent.
The value is described with a boolean value: “true” or “false”. The default value is“false”(4) Coding Example
This coding example shows a pretest with 80 points set as the passing score.
<item identifier="PRETEST1"><title>Pre-test</title><imsss:sequencing><imsss:objectives><imsss:primaryObjective objectiveID = "PRIMARYOBJ"
satisfiedByMeasure = "true"><imsss:minNormalizedMeasure>0.8</imsss:minNormalizedMeasure></imsss:primaryObjective></imsss:objectives></imsss:sequencing></item>(5) Note for Implementation
If the Objective Satisfied by Measure element is set to “True” the value of the
SCORM Run-Time Environment Data Model element (cmi.scaled_passing_score) is
initialized with the value set for the Objective Minimum Satisfied Normalized
Measure. This is the threshold value against which the objective’s satisfaction isevaluated.

1.1
Primary Objective
satisfiedByMeasure = “True”
minNormalizedMeasure = “0.8”

1.1.1

SCO

1.1.2
1.1.3

Manifest file

SCO
Data model
SCO

GetValue(“cmi.scaled_passing_score”)
Î 0.8 (Initial value)

Figure 6.11 Defining Threshold Point for Satisfaction Evaluation
An SCO sets the values for its objective information using the RTE Data Modelelements (cmi.objectives).

5

The SCORM CAM book specifies that only the objective defined in the <primaryObjective> element
contributes to the rollup of the parent activity. This means that the primary objective defined using the
primaryObjective element is the only objective that contributes to the rollup and the value of this
attribute is regarded as True for this objective.

88

SCORM 2004 Content Development Guide• cmi.objectives.n.success_status Æ Objective Satisfied Status• cmi.objectives.n.completion_status Æ Attempt Completion Status
To allow an SCO to set values to multiple local objectives, a collection of data model
elements is defined, and values are set to the data model elements corresponding toeach objective.

1.1
Setting a value for an objective

1.1.1

SetValue(“cmi.objectives.0.success_status”, “passed”)

1.1.2
1.1.3

SCO

Objective
学習目
Data model
Objective
学習目
Figure 6.12 Setting Objective Data

6.1.6.2 Specifying Shared Global Objectives(1) Overview
Each local objective may be connected to a shared global objective. In this way, thetracking information may be shared between activities for sequencing. A sharedglobal objective is associated with the local objectives of some activities so that theassociated activities can refer to the shared global objective under the following
conditions:• One local objective can be associated with one and only one shared global
objective• One shared global objective can be associated with multiple local objectives• One activity can refer to multiple shared global objectives via multiple local
objectives• A shared global objective can be updated through only one local objective.

89

SCORM 2004 Content Development Guide
1.

1.1

1.2

1.3

Local objective

Local
objective
ローカル学習目標
Write
Mapped(Can write)
mapinfowriteSatisfiedStatus= “True”

Read

Local objective
Read

Local objective

Read

Sharedglobal objective
共有グローバル学習
Shared global objective

Mapped(Can read)mapinforeadSatisfiedStatus= “True”

Figure 6.13 Shared Global Objectives(2) Specification Method
The <imsss:mapInfo> element is used to specify the relationships between
objectives within each objective description (<imsss:primaryObjective> and<imsss:objective>).
[Explanation of Parameters]a. Activity Objective ID
This indicates an identifier of a local objective associated with the activity. As
there is no default defined, this must be specified with a unique value.
b. Target Objective ID
This indicates an identifier of a shared global objective that is the target for
mapping. As there is no default defined, this must be specified with a unique value.
c. Read Objective Satisfied Status
This indicates whether the Objective Satisfied Status should be referred to andshould be specified with a boolean value. The default value is “True”.
d. Write Objective Satisfied Status
This indicates whether the Objective Satisfied Status should be set and should bespecified with a boolean value. The default value is “False”.
e. Read Objective Normalized MeasureThis indicates whether the Objective Normalized Measure should be referred toand should be specified with a boolean value. The default value is “True”.
f. Write Objective Normalized MeasureThis indicates whether the Objective Normalized Measure should be set andshould be specified with a boolean value. The default value is “False”.
(3) Coding Example
This coding example shows how to define a shared global object that can be written toby the associated activity.
90

SCORM 2004 Content Development Guide<item identifier="PRETEST1"><title>Pre-test</title><item identifier="Q1" isvisible = "false" identifierref="RQ1"><title>Question 1</title></item><imsss:sequencing><imsss:objectives><imsss:primaryObjective
objectiveID = "PRIMARYOBJ"
satisfiedByMeasure = "true"><imsss:minNormalizedMeasure>0.6</imsss:minNormalizedMeasure><imsss:mapInfo targetObjectiveID = "obj1"
readNormalizedMeasure = "false"
writeSatisfiedStatus = "true" /></imsss:primaryObjective></imsss:objectives></imsss:sequencing></item>(4) Note for Implementation
Activity objective IDs and target objective IDs are uniquely defined within the scope
where they are applied. However, it is desirable to make them unique also within theassociated content package to identify tracking information.

6.1.7 Specifying Other Controls
6.1.7.1 Selection and Randomization Controls(1) Overview
Selection and randomization controls are used to define how child activities in acluster are selected and how they are re-ordered before they are delivered to thelearner. These controls are classified into two behaviors.
• Selection controls: These controls are used to define how child activities are
selected. It is possible to define the timing for selection and the number ofactivities to be selected.
• Randomization controls: These controls are used to control how activities are reordered. It is possible to define whether the target child activities are to be reordered and the timing for that action.

91

SCORM 2004 Content Development Guide(At the first attempt)

Randomization controls
selectCount = “2”reorderChildren = “True”

11
1.1
1.1
1.2
1.2

1
1.1
1.2

(At n-th attempt)

1.3

1
1.3
1.3

Manifest file

1.2
1.2

Each activity

Figure 6.14 Selection and Randomization Controls(2) Specification Method
The selection and randomization controls are defined using the<imsss:randomizationControls> element in the manifest file.
(3) Explanation of Parameters
a. Select Count
This attribute indicates the number of child activities that must be selected fromthe associated cluster for the selection and randomization. The value is specified
with an integer value. The default value is 0. When the selectCount value is 0, no
activity is selected. If the value exceeds the number of all associated child
activities, all the child activities are selected.
b. Selection TimingThis attribute is used to define when the selection should occur. The value should
be one of the following tokens:
Token
never
once
onEachNewAttempt6

Table 6.9 List of Tokens for Selection Timing
Description
Selection does not occur. All child activities are regarded
as valid ones.
Selection occurs at the first attempt on the activity
Selection occurs every time a new attempt is made on theactivity

Default: “never”
c. Reorder Children
This attribute is used to indicate whether the child activities should be reorderedand should be specified with a boolean value. The default value is “False”.
d. Randomization Timing
6

The current SCORM standard does not specify the onEachNewAttempt attribute and its behavior.

92

SCORM 2004 Content Development Guide
This attribute is used to define when the randomization should occur. The value
should be one of the following tokens:
Table 6.9 List of Tokens for Randomization Timing
Description
Randomization does not occur
neverRandomization occurs at the first attempt on the activity
once
Randomization occurs ever time a new attempt is made on
onEachNewAttempt
the activity
Default: “never”
Token(4) Coding Example
This coding example shows how to define a case where two child activities are to be
selected from among three child activities.
<item identifier="POSTTEST1"><title>PostTest</title><item identifier="Q1" isvisible = "false" identifierref="RQ1"><title>Question 1</title></item><item identifier="Q2" isvisible = "false" identifierref="RQ2"><title>Question 2</title></item><item identifier="Q3" isvisible = "false" identifierref="RQ3"><title>Question 3</title></item><imsss:sequencing><imsss:randomizationControls selectCount="2"
selectionTiming="once" /></imsss:sequencing></item>6.1.7.2 Delivery Controls(1) Overview
Delivery controls indicate actions that should be taken prior to an attempt on an
activity. These controls are used for the management of tracking information on thecontent side that is expected to be used by LMSs.
(2) Specification Method
Delivery controls are defined using the <imsss:deliveryControls> element in the
Manifest file for each activity.
(3) Explanation of Parameters
a. Tracked
This element indicates whether the tracking information that includes theinformation about the activity’s objective progress, attempts and completionshould be tracked. The element contains a boolean value. The default value is“True”.
b. Completion Set By Content

93

SCORM 2004 Content Development Guide
This element indicates whether the Attempt Completion Status is to be set by the
SCO or not. The element contains a boolean value. If the value is set to “True”,
the attempt completion status of the activity cannot be changed by the LMS, andcan only be updated by the content (the SCO). The default value is “False”.
c. Objective Set By Content
This element indicates whether the Objective Satisfied Status is to be set by the
SCO or not. The element contains a boolean value. If the value is set to “True”,
the objective’s satisfaction status for the activity cannot be changed by the LMS,
and can only be updated by the content (the SCO). The default value is “False”.
(4) Coding Example
In this example, tracking information is not tracked for the activity.
<item identifier="L1" identifierref="RL1"><title>What is a Learning Objective?</title><imsss:sequencing><imsss:deliveryControls tracked = "false"/></imsss:sequencing></item>6.2 Features of SCORM 2004 SCOs
This section discusses the major points to note when implementing SCORM 2004
conformant SCOs.

6.2.1 RTE Usage Examples
6.2.1.1 Implementing an API Instance
When launched, an SCO must be able to find the LMS-provided API Instance toestablish a communication session with the LMS. To find the API Instance, the SCO
must search the following locations for the API Instance:• The chain of parents of the current window until the top parent is reached• The opener window, which is the window that has opened the SCO’s window• The chain of parents of the opener window until the top parent is reached.

94

SCORM 2004 Content Development Guide

Parent N
Parent 2
Parent 1
SCO

Chain of Parents

Parent N
Parent 2
Parent 1

SCO

Chain of Parents of the Opener
Figure 6.15 Finding the API Instance
The SCO must also be able to call the Initialize(“”) and Terminate(“”) API methods
once it has found the API Instance. The IEEE standard provides a simple
ECMAScript (JavaScript) coding example that shows how to find the API Instance.
As the standard does not require use of ECMAScript, however, other coding methods
can be used.
The code below shows an example of how to apply recursive searching for the API
Instance.

95

SCORM 2004 Content Development Guide<html><head><script type=”text/javascript”><!-//----- Find the API Instance ----var API = null;function FindAPI(win) {if ((typeof(win.API_1484_11) != “undefined”) &&(win.API_1484_11 != null)) {return win.API_1484_11;} else if (win.location == top.location) {return null;} else {return FindAPI(win.parent);}}
function MyInit() {// Locate the API frameif ((window.parent != null) && (window.parent != window)) {API = FindAPI(window.parent);}// To find the API Instance on the window opener
if ((API == null) && (window.opener != null)) {API = FindAPI(window.opener);}
if (API != null) {// Call the Initialize API method
API.Initialize("");} else {alert("Cannot find the API Instance．");}}
function MyFin() {if (API != null) {// Call the Terminate API method
API.Terminate("");
}
}
//-->
</script></head><body onload=”MyInit();” onunoad=”MyFin();”><h1>SCORM Sample Code</h1></body></html>6.2.1.2 Calling API Methods
This section discusses how to call API methods that are required when developing
SCORM compliant content.
(1) Using API Methods
a. Initialize
This method is used for an SCO to establish a communication session with the
LMS after having found the API Instance located in the API frame. The SCORM
standard specifies that the SCO must always make one Initialize method call.
b. Terminate

96

SCORM 2004 Content Development Guide
This method is used for an SCO to terminate the current communication session
with the LMS. The SCORM standard specifies that the SCO must always use thisAPI method with the Initialize method as a pair. The SCO should send therelevant data at the same time as it terminates its communication session with the
LMS.
c. GetValueThe GetValue method is used when the SCO retrieves data from the LMS. It is
possible for the SCO to use the obtained values after assigning them to variables
within the SCO’s scope.
d. SetValue and Commit
The SetValue method is used to set the data that will be sent to the LMS (after
being cached by the API Instance). The Commit method is used to forward to thepersistent data store of the LMS any data that has been cached by the API
Instance. To ensure that the data set with the SetValue method calls is saved by
the LMS in a persistent store, the Commit or Terminate method must be called.

97

SCORM 2004 Content Development Guide
Example 1: This example shows how the SCO retrieves the learner’s name from the
LMS and displays it on the screen.
<html><head><script type=”text/javascript”><!-//----- Find the API Instance. ----var API = null;function FindAPI(win) {//（Omitted）}
function MyInit() {// Locate the API frame.
if ((window.parent != null) && (window.parent != window)) {API = FindAPI(window.parent);}// Locate the opener window or API frame.
if ((API == null) && (window.opener != null)) {API = FindAPI(window.opener);}
if (API != null) {// Call the Initialize API method.
API.Initialize("");} else {alert("Cannot find the API Instance.");}}function MyFin() {if (API != null) {// Call the Terminate API method.
API.Terminate("");}}
function GetLearnerName() {var name = “”;if (API != null) {// Get the learner’s name.
name = API.GetValue(“cmi.learner_name”);}
return name;}//--></script></head><body onload=”MyInit();” onunoad=”MyFin();”><h1>SCORM EXAMPLE 1</h1><script type=”text/javascript><!—
document.write(“<p>Welcome! Dear ” + GetLearnerName() + “.</p>”);//--></script></body></html>98

SCORM 2004 Content Development Guide
Example 2: This example shows how the SCO keeps track of the learner’s answers
and stores the result at the LMS.
<html><head><script type=”text/javascript”><!-//----- Find the API Instance.----var API = null;function FindAPI(win) {//（Omitted）}
function MyInit() {// Locate the API frame.
if ((window.parent != null) && (window.parent != window)) {API = FindAPI(window.parent);}// Locate the opener window or the API Instance frame.
if ((API == null) && (window.opener != null)) {API = FindAPI(window.opener);}
if (API != null) {// Call the Initialize API method.
API.Initialize("");} else {alert("Cannot find the API Instance.");}}function MyFin() {if (API != null) {// Call the Terminate API method.
API.Terminate("");}}
function SetAnswer() {var ans = document.form1.text1.value;
if (API != null) {//Save the answer data.
API.SetValue(“cmi.interactions.0.learner_response”,
ans);//Commit the answer data to the LMS.
API.Commit(“”);
}
}
//-->
</script></head><body onload=”MyInit();” onunoad=”MyFin();”><h1>SCORM Example 2</h1><br><form name=”form1"><p><input name="answer1” type="text" size="20"><input type="button" value="Answer" onclick=”SetAnswer();”></p></form></body></html>99

SCORM 2004 Content Development Guide(2) Handling API Errors
When an error occurs during a state transition of the API Instance, an error code is set
at the API Instance. SCOs must be implemented in such a way that they should be
able to handle the possible error conditions for all API method calls.
The API Instance provides a set of support methods that the SCOs can call todetermine the errors. The support methods include GetLastError, GetErrorString and
GetErrorDiagnostic.
The following example shows how to handle errors.
<html><head><script type=”text/javascript”><!-var API = null;function FindAPI(win) {(Omitted)}function MyInit() {(Omitted)}function MyFin() {(Omitted)}//-----Check the error.----function CheckError() {var errMsg = "";if (API != null) {if (parseInt(API.GetLastError()) > 0) {errMsg = API.GetErrorString() + ":" +API.GetDiagnostic();
alert(errMsg);
}
}
}
//-->
</script></head><body onload=”MyInit();” onunoad=”MyFin()”><h1>SCORM Example</h1></body></html>100

SCORM 2004 Content Development Guide

6.2.1.3 Using the RTE Data Model
The RTE Data Model is a collection of data model elements used for communication
between the LMS and SCOs. When the LMS and the SCOs communicate with eachother, both assume that the other party knows about each of these data model
elements. The major uses of these data model elements in communication are• Initialization• Reading data
• Writing data
• Saving and storing
The usage patterns of data model elements are read-only, write-only, and read andwrite.
(1) Read-Only Data Model Elementsa. Examples
Example 1: Learner’s ID
id = GetValue(“cmi.learner_id”);

Example 2: The launch data of the SCO
Lprm = GetValue(“cmi.launch_data”);

Example 3: Maximum attempt duration on the SCO
TimeAllowed = GetValue(“cmi.max_time_allowed”);

b. Behaviors• The LMS performs initialization using the session data and the information
concerning the content structure.
• SCOs utilize this data after retrieving it from the LMS.
• The SCOs cannot change or update this data.
c. Explanation
The learner’s ID information in Example 1 is assumed to be initialized by the
LMS using the session data.
The cmi.launch_data element in Example 2 and the cmi.max_time_allowed
element in Example 3 are initialized by the LMS using the values defined in the
manifest file (imsmanifest.xml).
Example 2: SCO launch data is initialized with the value defined in<adlcp:dataFromLMS>.
Example 3: The maximum attempt duration on the SCO is initialized with thevalue defined in <imsss:attemptAbsoluteDurationLimit>.

101

SCORM 2004 Content Development Guide
Requests data with
GetValue(“cmi.launch_data”);<adlcp.dataFromLMS>[Initial value]</adlcp:dataFromLMS>

SCO

LMS

Manifest fileData
display

Returns values initialized fromthe manifest file.

Figure 6.16 Using Data Model Elements (Read-only)
For these read-only data model elements, there are corresponding elements
defined in the manifest file for their initial values.
Table 6.10 List of Data Model Elements Initialized from the Manifest File
Data Model Element Name
Description
Element Name in Manifest File
Indicates a value against which the
cmi.completion_thresholdlearner’s completion of the SCO is<adlcp:completionThreshold>evaluated
Parameters that the SCO can use forcmi.launch_data
initialization<adlcp:dataFromLMS>
Indicates the maximum amount of
cmi.max_time_allowed
time allowed for an attempt on the<imsss:attemptAbsoluteDurationLimit>
SCO
Indicates a value against which the
cmi.scaled_passing_score
objective satisfaction measure is to be<imsss:minNormalizedMeasure>evaluated
Indicates an action to be taken when
cmi.time_limit_action
the maximum allowed time has been
<adlcp:timeLimitAction>
reached(2) Write-Only Data Model Elementsa. Example
Example 4: Session time
SetValue(“cmi.session_time”, “05:15:00”);

b. Behaviors• The LMS does not perform initialization.
• The SCO sets a value to the specified data model element.

102

SCORM 2004 Content Development Guide• The LMS processes, saves and stores the information.
c. Explanation• The data model elements are used mainly for storing the learner’s performanceand progress data with an SCO.
Requests with
SetValue(“cmi.session time”, “05:15:00”);

The LMS tracks thesession time.

SCO

LMS

Manifest fileLearner’s
interaction
Figure 6.17 Using Data Model Elements (Write)(3) Read and Write Data Model Elementsa. Examples
Example 5: Reading the learner’s success status.
Loc = GetValue(“cmi.success_status”);

Example 6: Writing the learner’s success status data.
SetValue(“cmi.success_status”, “passed”);

b. Behaviors• The LMS initializes the associated data model elements as “unknown”.
• The SCO uses the data after retrieving it and then updates it.
• The LMS processes, saves and stores the information.
• The SCO may use the data again after retrieving the updated data.
c. Explanation• The data model elements for reading and writing are used to capture statechanges during a session such as progress status, success status andperformance measures.
• The SCO is supposed to initialize these data model elements.
• As state values and numerical values are used, errors are caused if the values
are not within the defined set of keywords or within the allowed range.

103

SCORM 2004 Content Development Guide

Update the success status with
SetValue(“cmi.success_status”, “passed”);
The LMS initializes the data model
elements as “unknown”.

SCO

LMS
Manifest fileLearner’s
interaction

Retrieves the success status value with
GetValue(“cmi.success_status”);

Figure 6.18 Using Data Model Elements (Read/Write)

6.2.2 Example Uses of Navigation
SCORM 2004 allows the navigation of SCOs to be controlled from within an SCO.
• A navigation request event can be triggered within an SCO for another SCO.
• It is now possible for an SCO to request that the LMS hide or show the LMSprovided user interface devices.
This section explains how to use this feature.
6.2.2.1 Navigation Requests from an SCO(1) Overview
In addition to the LMS-provided user interface devices for navigation, SCORM 2004
allows an SCO to trigger such navigation request events as Continue and Previous.
(2) Specification Method
A navigation request event can be triggered from content (SCOs) using theadl.nav.request RTE data model element in a SetValue API method call.
(3) Explanation of Parameters
Table 6.11 shows a list of navigation control requests that can be used in the API
method call.
Parameter
continuepreviouschoiceTable 6.11 List of Navigation Requests from SCOs
Description
Terminate the current SCO and issue a continue
navigation request
Terminate the current SCO and issue a previous
navigation request
Terminate the current SCO, and issue a navigation
request to move to a specified SCO
104

SCORM 2004 Content Development Guide
Parameter
exit
exit allabandonabandon all_none

Description
Terminate the current SCO
Terminate the current activity tree
Abandon the current activity
Abandon the current activity tree
Clears unprocessed navigation requests(4) Coding Example
Example 1: To trigger a Continue navigation event
SetValue(“adl.nav.request”, “continue”);

Example 2: To trigger a Choice navigation event by selecting activity A1 as the target
SetValue(“adl.nav.request”, “{target=’A1’}choice”);

To trigger a Choice navigation event, the target activity to move to must be specified.
(5) Points to Note
• Navigation request events are not processed by the LMS until the Terminate API
method call is successfully processed. This means that the Terminate method
must be invoked after a SetValue method has been issued in order to trigger anavigation request event.
•

Depending on the LMS implementation, some navigation requests made by
SCOs might not be honored, so it is necessary for the SCOs to confirm thevalidity of the navigation requests they make and an appropriate measure forhandling the requests that cannot be made must be implemented. SCOs should be
able to check the validity of each request with the LMS through theadl.nav.request_valid RTE Data Model element.

6.2.2.2 Controlling LMS-Provided UI Devices from the Manifest File
(1) Overview
In SCORM 2004, whether the LMS-provided user interface devices are to be shownor hidden can be controlled.
(2) Specification Method
Whether the LMS-provided user interface devices are to shown or hidden can be
defined for each activity using the <adlnav:presentation> element in the manifest file.
(3) Explanation of Parameters
The LMS-provided user interface devices can be controlled with the <hideLMSUI>
element definitions under the <adlnav:presentation> element using the tokens shownin Table 6.12.

105

SCORM 2004 Content Development Guide
Table 6.12 List of Tokens for Controlling LMS-provided UI Devices
Parameter
Description
Hide the UI device for backward navigation
previous
Hide the UI device for forward navigation
continue
Hide the UI device for Exit
exit
Hide the UI device for Abandon
abandon(4) Coding Example<organization><item identifier=”item1” identifierref=”Resource1” isvisible=”true”><adlnav:presentation><adlnav:navigationInterface><adlnav:hideLMSUI>continue</adlnav:hideLMSUI><adlnav:hideLMSUI>previous</adlnav:hideLMSUI></adlnav:navigationInterface></adlnav:presentation></item></organization>

106

SCORM 2004 Content Development Guide

7 Migration from SCORM 1.2 to SCORM 2004
Although SCORM 2004 is the successor standard of SCORM 1.2, it is not completely
upwardly compatible with SCORM 1.2. To run SCORM 1.2 compliant content undera SCORM 2004 compliant LMS, the content must therefore be converted fromSCORM 1.2 to the SCORM 2004 standard.
This section describes the differences between the two versions and explains how toconvert content to the new standard.

7.1 Manifest File and SCOs
In SCORM 2004, the Run-Time Environment data model and content aggregation
model have been upgraded from SCORM Versions 1.2 to 1.3.1. The sequencing andnavigation features have also been added.
A SCORM content package consists of a manifest file and SCOs; the content
packaging side is related to the manifest file, while the Run-Time Environment isclosely related to the SCOs. As the content aggregation model and the Run-Time
Environment have been upgraded in SCORM 2004, both the manifest file and SCOs
developed in SCORM 1.2 must be converted to the SCORM 2004 standard and a setof sequencing rules must be defined in the manifest file.

7.2 Converting the Manifest FileIn principle, SCORM 2004 compliant manifest files are upwardly compatible with
SCORM 1.2 manifest files. In a SCORM 2004 environment, a SCORM 1.2 manifest
file is regarded as a SCORM 2004 manifest file which does not contain any
sequencing rule definitions.
The old manifest files must be changed, though, as some elements specified in
SCORM 1.2 have been removed and changes have been made to content packaging.
The major changes that must be made to the manifest file are as follows:• Updated XML Binding• Changes to ADL content packaging extension elements (prerequisites andmasteryscore)• Sequencing control mode specification• Metadata description
These changes to the manifest file are explained below.

7.2.1 Basic Structure
The basic structure of the manifest file (imsmanifest.xml) is a hierarchical tree
structure in both SCORM 1.2 and SCORM 2004, and this basic structure has not beenchanged. Thus, the <metadata>, <organizations> and <resources> elements which
represent the basic content structure are the same in both versions.

107

SCORM 2004 Content Development Guide

7.2.2 Content Packaging
Due to the changes made to the IMS namespace declarations and metadata XML
binding specifications that SCORM is based on, the content packaging specification
has been changed in SCORM 2004. For this reason, it is necessary to modify various
declarations in the manifest files developed under the earlier version. These changes
are summarized in Table 7.1.

IMS
namespacedeclaration
ADL
namespacedeclaration
Metadata
XML binding
namespace

Table 7.1 Changes to Content Packaging
SCORM 1.2
SCORM 2004
http://www.imsproject.org/xsd/
http://www.imsproject.org/xsd/
imscp_rootv1p1p2
imscp_v1p1
http://www.adlnet.org/xsd/adlcp_ http://www.adlnet.org/xsd/adlcp_
rootv1p2
v1p3
http://www.imsglobal.org/xsd/
imsmd_rootv1p2p1

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

In addition, changes have been made to some ADL content packaging extension
elements, as shown in Table 7.2
Table 7.2 Changes to ADL Content Packaging Extension Elements
SCORM 1.2
SCORM 2004
Removed (Use a sequencing rule definition)<adlcp:prerequisites>
Removed (Use a sequencing rule definition)<adlcp:maxtimeallowed><adlcp:timelimitaction><adlcp:timeLimitAction><adlcp:datafromlms><adlcp:dataFromLMS>
Removed (Use a sequencing rule definition)<adlcp:masteryscore><adlcp:scormtype><adlcp:scormType>7.2.3 Changes to the Prerequisites and Masteryscore Elements
A particularly important point to note is that <adlcp:prerequisites> for defining
prerequisites, <adlcp:masteryscore> for setting a threshold value for passing, and<adlcp:maxtimeallowed> for defining the maximum allowed time have been
removed from the ADL content packaging extension elements and replaced withsequencing rule definitions.
As these ADL content packaging extension elements were treated inconsistently bydifferent LMS implementations in SCORM 1.2, they caused interoperability problems.
These conditions can be described as sequencing rules in SCORM 2004. Thisenhancement enables improved interoperability and clearer definition of conditions.
This section explains how to convert the definitions of the prerequisites andmasteryscore extension elements.

108

SCORM 2004 Content Development Guide
7.2.3.1 Converting Prerequisites Definitions
In SCORM 1.2, whether a particular activity (with an SCO or an asset) is valid for alearner was defined with the prerequisites ADL content packaging extension element.
As it is possible to define various behaviors of an activity through a set of sequencing
rules in SCORM 2004, however, the delivery limits for an activity that had been
defined in this prerequisites element can now be described in the sequencing rules.
Therefore, the prerequisites extension element has been removed in SCORM 2004.
(1) Precondition Rules
There are a few different ways to control the delivery of activities; this section
explains how to do it using precondition rules.
A condition for the delivery of an activity can be defined using precondition rules.
Precondition rules are defined for each activity on the basis of the following structure:
If [condition_set] Then [action]
The condition set is a logical expression that is evaluated as True or False dependingon the tracking information. The action is the limit on the delivery of the associatedactivity. The example below shows a case where the delivery of an activity is limitedusing a precondition rule.
Example:If not completed Then stopForwardTraversal
This precondition rule indicates that if a learner has not completed the activity thenthe learner cannot move forward.
The above precondition rule is expressed in the manifest file as follows:<item identifier = "SAMPLE1"><title>You Cannot Proceed.</title><imsss:sequencing><imsss:sequencingRules><imsss:preConditionRule><imsss:ruleConditions><imsss:ruleCondition condition = "completed"
operator = "not"/></imsss:ruleConditions><imsss:ruleAction action = "stopForwardTraversal"/></imsss:preConditionRule></imsss:sequencingRules></imsss:sequencing></item

7.2.3.2 Converting Masteryscore Definitions
In SCORM 1.2, the threshold score for deciding pass or failure was defined using themasteryscore ADL content packaging extension element. In SCORM 2004 this109

SCORM 2004 Content Development Guide
definition is described in the manifest file (imsmanifest.xml) as a set of sequencing
rules that correspond to the definition
More specifically, the passing score for an SCO is defined with the<imsss:objectives> element. For an activity for which this condition is set, a passing
score is defined by setting the satisfiedByMeasure attribute to True and then defining
a threshold value in the <imsss:minNormalizedMeasure> element. This value is used
to initialize the “cmi.scaled_passing_score” SCORM RTE Data Model element.
The example below shows how a passing score of 0.7 (70 points out of 100) is
specified in the manifest file as the threshold value for the objective.

<item identifier="item1"><title>Practical Exercise</title><imsss:sequencing><imsss:objectives><imsss:primaryObjective objectiveID="obj1"
satisfiedByMeasure="True"><imsss:minNormalizedMeasure>0.7</imsss:minNormalizedMeasure></imsss:primaryObjective></imsss:objectives></imsss:sequencing></item>The passing value provided from the manifest file is used by the SCO after the SCO
retrieves it from the Run-Time Environment data model element
cmi.scaled_passing_score, which has been added in SCORM 2004.
For example, the code
masteryscore = GetValue(“cmi.scaled_passing_score”) * 100;

causes the SCO to retrieve the passing value that was initialized from the manifest file,multiply it by 100, and then save the result of “70”in the variable masteryscore.

7.2.4 Defining Sequencing Control Modes
7.2.4.1 Sequencing Control Modes
In SCORM 2004, the navigation behavior of a cluster is controlled using sequencing
control modes. For example, to allow the learner to use the LMS-provided userinterface devices for moving forward (continue) or backward (previous), theSequencing Control Flow is defined as True; to allow the learner to select the next
activity from the menu, the Sequencing Control Choice is defined as True.
If no sequencing control mode is defined, some LMS implementations may not
deliver an activity while some may issue an error message.
Sequencing control modes are defined using the <imsss:controlMode> element foreach cluster in the manifest file.

110

SCORM 2004 Content Development Guide

An example of the definition of a sequencing control mode is shown below:<imsss:sequencing><imsss:controlMode choice="true" choiceExit="true" flow="true"
forwardOnly="false"/></imsss:sequencing>

7.2.4.2 Attempt-Related Sequencing Control Modes
In SCORM 2004, it is possible to specify for a cluster whether to use information
about the objective progress (Use Current Attempt Objective Information) and attempt
progress (Use Current Attempt Progress Information) of the current attempt only or
the latest information including the most recent previous attempt. The attributes to be
defined in the controlMode element for these two are useCurrentAttemptObjectiveInfo
and useCurrentAttemptProgressInfo, respectively.
The default values of the Use Current Attempt Objective Information and the Use
Current Attempt Progress Information are True. If this control mode is omitted, only
the current attempt information is used.
To use the latest information, including the most recent previous attempt, thesecontrol modes must be set to False.

7.2.5 Metadata Description
The Content Aggregation Metadata Application Profile has been changed in SCORM
2004, and the <metadata>, <schema> and <schemaversion> elements have eachbecome mandatory.7 It is therefore necessary to check whether these elements aredefined in the manifest file and define them if necessary.
The example below shows part of a manifest file in which these elements are defined:<metadata><schema>ADL SCORM</schema><schemaversion>CAM 1.3</schemaversion></metadata>

7

As from SCORM 2004 3rd edition.

111

SCORM 2004 Content Development Guide

7.3 SCO Migration
To perform SCO migration from SCORM 1.2 to SCORM 2004, the following actions
must be taken:• Change the API Instance name
• Change API method names• Change Data Model elements• Accommodate error code changes
This section describes how to make these changes to convert SCOs to SCORM 2004.

7.3.1 API Instance Name Change
In SCORM 1.2, the name of the SCORM API Instance8 was “API”. This has beenchanged to “API_1484_11” in SCORM 2004.
When an SCO invokes the FindAPI function to find the API Instance, the parameter
indicating the name of the API Instance must be changed to “API_1484_11”.

7.3.2 API Method Name Changes
The names of the API methods have been changed in SCORM 2004. Although there
is no change to the syntax, it is necessary to change the names of these API methods.
The API methods have been renamed as follows:
Table 7.3 API Method Name Changes
SCORM 1.2
SCORM 2004
LMSInitialize
Initialize
LMSFinish
Terminate
LMSGetValue
GetValue
LMSSetValue
SetValue
LMSCommit
CommitLMSGetLastError
GetLastError
LMSGetErrorString
GetErrorString
LMSGetDiagnostic
GetDiagnostic

7.3.3 Changes to Data Model Elements
In SCORM 2004, some RTE Data Model elements have been changed or added. To
convert SCOs to SCORM 2004, it is therefore necessary to modify the SCOs to suitthe SCORM 2004 RTE Data Model specification.
This section covers the major data model elements that require special attention when
migrating from SCORM 1.2 to SCORM 2004.

8

It was called the API Adapter until SCORM 1.2.

112

SCORM 2004 Content Development Guide
7.3.3.1 Changed or Removed Data Model Elements
Some SCORM 1.2 data model elements have undergone a name change while others
have been removed from the data model in SCORM 2004. To perform SCO migration,
it is therefore necessary to modify the names of data model elements as required andreplace deleted data model elements with new ones.
Table 7.4 shows the correspondence of data model elements between SCORM 1.2 andSCORM 2004.
Table 7.4 Correspondence of Data Model Elements between
SCORM 1.2 and SCORM 2004
SCORM 1.2 Data Model

SCORM 2004 Data Model−

cmi.comments

cmi.comments_from_lms

cmi.core._children
cmi.core.credit
cmi.core.entry
cmi.core.exit
cmi.core.lesson_location
cmi.core.lesson_mode

cmi.core.score._children
cmi.core.score.max
cmi.core.score.min
cmi.core.score.raw−
cmi.core.session_time
cmi.core.student_id
cmi.core.student_namecmi.core.total_time
cmi.interactions._children
cmi.interactions._countcmi.interactions.n.correct_responses._countcmi.interactions.n.correct_responses.n.pattern−
cmi.interactions.n.id
cmi.interactions.n.latency
cmi.interactions.n.objectives._countcmi.interactions.n.objectives.n.id

cmi._version
cmi.comments_from_learner._children
cmi.comments_from_learner._countcmi.comments_from_learner.n.comment
cmi.comments_from_learner.n.location
cmi.comments_from_learner.n.timestamp
cmi.comments_from_lms._children
cmi.comments_from_lms._countcmi.comments_from_lms.n.comment
cmi.comments_from_lms.n.location
cmi.comments_from_lms.n.timestamp

New−

RemovedReplaced
Replaced
Replaced
Replaced
Replaced

cmi.credit
cmi.entry
cmi.exit
cmi.location
cmi.mode
cmi.success_status
cmi.completion_status
cmi.score._children
cmi.score.max
cmi.score.min
cmi.score.raw
cmi.score.scaled
cmi.session_time
cmi.learner_id
cmi.learner_namecmi.total_time

cmi.core.lesson_status

Remarks

cmi.interactions._children
cmi.interactions._countcmi.interactions.n.correct_responses._countcmi.interactions.n.correct_responses.n.pattern
cmi.interactions.n.description
cmi.interactions.n.id
cmi.interactions.n.latency
cmi.interactions.n.objectives._countcmi.interactions.n.objectives.n.id

113

Replaced

Replaced

Replaced
Replaced
Replaced
Replaced
Replaced
New
Replaced
Replaced
Replaced
ReplacedNewSCORM 2004 Content Development Guide
SCORM 1.2 Data Model

SCORM 2004 Data Model

cmi.interactions.n.result
cmi.interactions.n.student_response
cmi.interactions.n.time
cmi.interactions.n.type
cmi.interactions.n.weighting

cmi.interactions.n.result
cmi.interactions.n.learner_response
cmi.interactions.n.timestamp
cmi.interactions.n.type
cmi.interactions.n.weighting

cmi.launch_data

cmi.launch_data

cmi.objectives._children
cmi.objectives._countcmi.objectives._children
cmi.objectives._countcmi.objectives.n.description
cmi.objectives.n.id
cmi.objectives.n.progress_measure
cmi.objectives.n.score._children
cmi.objectives.n.score.max
cmi.objectives.n.score.min
cmi.objectives.n.score.raw
cmi.objectives.n.score.scaled
cmi.objectives.n.success_status
cmi.objectives.n.completion_status−
cmi.objectives.n.id−
cmi.objectives.n.score._children
cmi.objectives.n.score.max
cmi.objectives.n.score.min
cmi.objectives.n.score.raw−
cmi.objectives.n.status

Remarks
Replaced
Replaced

New
New

New
Replaced

cmi.student_data._children
cmi.student_data.mastery_score
cmi.student_data.max_time_allowed
cmi.student_data.time_limit_action−
cmi.scaled_passing_score
cmi.max_time_allowed
cmi.time_limit_action.

RemovedReplaced
Replaced
Replaced

cmi.student_preference._children
cmi.student_preference.audio
cmi.student_preference.language
cmi.student_preference.speed
cmi.student_preference.text

cmi.learner_preference._children
cmi.learner_preference.audio_level
cmi.learner_preference.language
cmi.learner_preference.delivery_speed
cmi.learner_preference.audio_captioning

Replaced
Replaced
Replaced
Replaced
Replaced

cmi.suspend_data

cmi.suspend_data−−

cmi.completion_thresholdNew

cmi.progress_measure

New

In addition, data model elements have been introduced in SCORM 2004 that enable
SCOs to communicate navigation requests or check the validity of such requests.
Table 7.5 Data Model Elements for Navigation Requests and Validity Checking
SCORM 2004 Data Model Elements
adl.nav.request
adl.nav.request_valid.previous
adl.nav.request_valid.continue
adl.nav.request_valid.choice
7.3.3.2 Changes to Lesson Status
In SCORM 1.2, the objective satisfaction status and the attempt completion status
information was managed with one data model element called“cmi.core.lesson_status”. This caused problems in the management of learning data.

114

SCORM 2004 Content Development Guide

For example, it was not possible to handle situations where the learner was not to be
regarded as successful if he or she could not understand the content after completing itfrom start to end, or conversely the learner was to be regarded as successful if he or
she understood the content without completing it. This was because it was notpossible to represent the states of “completed” but “not satisfied”, or “incomplete” but“satisfied”, with the single data model element “cmi.core.lesson_status”.
In SCORM 2004, the data model elements have been changed in such a way that thecompletion status and success status are separately managed. In place of“cmi.core.lesson_status”, which has been removed, the two data model elements“cmi.completion_status” and “cmi.success_status” have been added to handle,
respectively, the completion status and the success status of a lesson.
“cmi.completion_status” is the data model element for managing information
concerning whether an attempt is completed. This data model element contains one of
the following tokens:completedincomplete
not attempted
unknown
Note that the state token “browsed” used in SCORM 1.2 is no longer used.
“cmi.success_status” is the data model element for managing the learner’s successstatus for an activity to indicate whether the learner has mastered the content. Thisdata model element contains one of the following tokens:
passedfailedunknown
When translating “cmi.core.lesson_status” into the “cmi.completion_status” or“cmi.success_status” pair, it is necessary to make sure that the content developer’s
intended information is correctly reflected by identifying whether the existing
information indicates a completion status or success status.
7.3.3.3 Data Type Clarification
SCORM 2004 specifies the minimum and maximum values and sizes for character
strings that are used as values for the data model elements. It also explicitly specifies
the smallest permitted minimum (SPM) value for each data model element that a
LMS must guarantee, and the new SCORM standard imposes a stricter data typedescription method.
When migrating from SCORM 1.2 to SCORM 2004, it is necessary to check content
packages to make sure the values of the data model elements are correctly typed
according to the standard and do not exceed the allowed range.
The data types specified in SCORM 2004 are as follows:• characterstring• localized_string_type
115

SCORM 2004 Content Development Guide• language_type• long_identifier_type• short_identifier_type• integer• state• real(10,7)• time(second,10,0)• timeinterval(second,10,2)
7.3.3.4 Detailed Specifications on Interactions
To improve the interoperability of the learner’s log data format for practical exercise
questions, the description format of replies and answers has been enhanced in
SCORM 2004 in the areas of data types, the value space and expressions.
When migrating from SCORM 1.2 to SCORM 2004, it is necessary to check thecontent packages to ensure correct adherence to the enhanced specification.
When enabling SCOs to migrate to SCORM 2004, it is also necessary to watch forminor changes like the change of the question type name from “choice” to“multiple_choice”.
7.3.3.5 Suspend Data
In SCORM 1.2, an SCO could save some values to the “cmi.suspend_data” data
model element and the LMS could refer to these at any time during the run-time. For
this reason, this data model element was used for various purposes. It was possible tosave old scores and answers in the “cmi.suspend_data”, and then refer to the values atthe subsequent launch time. It was also possible to save the learner’s progress
information within an SCO in this data model element so that the lesson could beresumed from the interrupted point by retrieving the saved information from the data
model element at the next start time.
In SCORM 2004, however, the “cmi.suspend_data” data model element can be savedon the LMS side only when the associated SCO is suspended (Suspend All). Therefore,
when an SCO is terminated with the “Continue”, “Exit All” or “Abandon All”
sequencing request, the “cmi.suspend_data” data model element cannot be used. The“cmi.suspend_data” data model element becomes valid in SCORM 2004 only whenan SCO is resumed after it was suspended.
In SCORM 2004, for this reason, it is necessary to use such data model elements as“cmi.location” rather than “cmi.suspend_data” for the above purposes. The
cmi.location data model element is used to store a bookmark or checkpoint of an SCO.
An SCO can save some values to the cmi.location and the LMS can refer to them as
well.
The example below shows how to use the cmi.location data model element:
GetValue(“cmi.location”);
SetValue(“cmi.location”, “chkPt1.p3.f5”);

116

SCORM 2004 Content Development Guide

Note that as the smallest permitted minimum (SPM) for the “cmi.location” data model
element is 1000 characters while that for the cmi.suspend_data is 4000, caution isrequired when using these data model elements.
In addition, as well as being able to write values to the interactions data model
element on the LMS, an SCO can retrieve the values from the LMS. For example, toutilize the interactions data model element to save a learner’s practical exercise data,
answers and scores, the “cmi.interactions.n.learner_response” and“cmi.interactions.n.learner_result” data model elements can be used.
7.3.3.6 The LMS must Implement All Data Model Elements
A SCORM 2004 conformant LMS is required to implement all the data model
elements. Under SCORM 1.2, SCOs could use only a limited number of data model
elements depending on the LMS implementation, but this limitation has been lifted as
it is mandatory that the LMS implement all data model elements.
When enabling SCOs to migrate to SCORM 2004, it is helpful to understand the usesof the RTE data model elements and then utilize the data model elements as required.

7.4 Changes to Error Codes
A more detailed error code structure has been introduced in SCORM 2004 to make itpossible to check the state transitions of the API Instance and the validity of data
elements. When migrating to SCORM 2004, it is therefore necessary to make changes
to the SCOs so that they can correctly respond to the new range of error codes.
Table 7.6 compares the error codes between SCORM 1.2 and SCORM 2004.
Table 7.6 Error Code Comparison between SCORM 1.2 and SCORM 2004
SCORM 1.2 Error CodeSCORM 2004 Error Code0 – No error
101 – General Exception

0 – No error
101 – General Exception
102 – General Initialization Failure
103 – Already Initialized
104 – Content Instance Terminated
111 – General Termination Failure
112 – Termination Before Initialization
113 – Termination After Termination
122 – Retrieve Data Before Initialization
123 – Retrieve Data After Termination
132 – Store Data Before Initialization
133 – Store Data After Termination
142 – Commit Before Initialization
143 – Commit After Termination
201 – General Argument Error

201 - Invalid argument error
202 - Element cannot have children
203 - Element not an array. Cannot
have count

301 – General Get Failure
351 – General Set Failure

117

SCORM 2004 Content Development Guide
SCORM 1.2 Error CodeSCORM 2004 Error Code391 – General Commit Failure
401 – Undefined Data Model Element402 – Unimplemented Data Model Element403 – Data Model Element Value Not
Initialized
404 – Data Model Element Is Read Only

401 - Not implemented error
401 - Not implemented error
301 - Not initialized
403 - Element is read only
404 - Element is write only
402 - Invalid set value, element
is a keyword
405 - Incorrect Data Type405 – Data Model Element Is Write Only
406 – Data Model Element Type Mismatch
407 – Data Model Element Value Out Of
Range
408 – Data Model Dependence Not
Established

For the changes to the error codes, it is necessary to check the SCOs in the areas
concerning the learner interactions and the state transitions of the API Instance wheremost of the specification changes have been made.

7.5 The Potential of SCORM 2004
This section has so far described how to realize the functions of SCORM 1.2 content
under SCORM 2004, and explained the major points to note when converting
SCORM 1.2 content to SCORM 2004. The first critical step of the content migration
effort is to enable the content to run correctly in a SCORM 2004 Run-Time
Environment.
However, content developers should also recognize the huge potential that SCORM
2004 offers. For example, they can take advantage of sequencing rules in developing
content that can display a dynamic behavior in response to the sequence of learning
experiences and the status of learning progress. They can also provide the optimaluser interface for their intended learners through the new ability to trigger navigation
request events from within the content. The main enabling factor is that a SCORM
2004 conformant LMS is now required to implement all the data model elements.
Furthermore, as the concept of learning objectives is refined, applying a more realistic
approach to the development of content that fulfills educational policies as intended
will become increasingly practical.
Compared with SCORM 1.2, SCORM 2004 has enhanced the degree of freedom withwhich content developers can apply a variety of design strategies to their content
development process. It is up to the content developers whether they will takeadvantage of this new potential. It is hoped that they will not be satisfied by merely
ensuring their content will run in a SCORM 2004 environment – instead they should
be engaged in developing more effective, easy-to-use content by taking advantage ofthe potential of SCORM 2004.

118

SCORM 2004 Content Development Guide

Index
Migrating, 107
masteryscore, 109
Migration to SCORM 2004, 107
Navigation, 36, 104
Navigation control, 36
Navigation request, 16, 104
Navigation request event, 38
Objective, 12, 86
Objective measure rollup, 26
Objective rollup, 26
Post condition rules, 24
Postcondition rules, 79
Precondition rules, 78
Precondition sequencing rules, 21
prerequisites, 109
Primary objective, 12, 13, 25, 26, 27,
29, 34Progress rollup, 27
real, 62
Rollup, 25
Rollup rules, 25, 28, 72, 80, 81, 83, 84
RTE, 6, 42, 94, 112
RTE data model, 58, 63, 101
RTE data model elements, 58, 112
SCO, 43, 45, 94, 107, 112
SCO migration, 112
SCORM, 4
SCORM 1.0, 7
SCORM 1.1, 7
SCORM 1.2, 8, 107
SCORM 2004, 5
Migration, 107
SCORM 2004 Overview, 6
SCORM run-time environment, 42
SCORM Run-Time Environment, 6
SCORM run-time environment data
model, 58
SCORM Sequencing and Navigation, 6
SCO's navigation event, 37
Sequencing, 12, 72
Sequencing conrol Choice Exit, 20
Sequencing control Choice, 19
Sequencing control Flow, 19
Sequencing control Forward Only, 20
Sequencing control modes, 19, 72, 110
Sequencing request, 16
Sequencing rules, 18, 75

Activity, 12
Activity tree, 12API, 44
API adapter, 44
API error codes, 52, 117
API instance, 44, 51, 112
API instance state transition, 51
API methods, 47, 96, 112
Asset, 43
Attempt, 35, 111
CAM, 6
Changes from SCORM 1.2, 8
characterstring, 61
Cluster, 12, 72
Content Aggregation Model, 6Content packaging, 108Content structure, 12Controlling LMS-provided UI devices,
105
Data model, 101
Data model elements, 9, 58, 65, 101,
113
Data model extension, 63
Data types, 61
Delivery controls, 93
DOM, 46
ECMAScript, 46
Exit action rules, 24
Exit rule, 80
integer, 62interactions, 116
language type, 62
Launching learning resources, 43
Leaf activity, 12lesson_status, 114
Limit condition, 21
Limit conditions, 85
LMS, 45
LMS model, 5
LMS-provided navigation devices, 40
LMS-provided UI devices, 105
Local objective, 89
Local objectives, 86
localized string type, 61long identifier type, 62
Manifest file, 6, 8, 9, 12, 40, 65, 67, 68,
69, 71, 72, 107
119

SCORM 2004 Content Development Guide
time, 62
timeinterval, 62
Tracking data, 14Tree structure, 12
Use Current Attempt Objective
Information, 20
Use Current Attempt Progress
Information, 20

Sharable Content Object (SCO), 43
Sharable Content Object Reference
Model, 4, 7
Shared global objective, 86, 87, 89, 90
Shared global objectives, 86
short identifier type, 62
state, 62
Suspend data, 116
Termination request, 16

120

SCORM 2004 Content Development Guide

About This Document
Acknowledgements
This document was a translation of a Japanese document authored by the following
people:Sections 1, 2, and 4 – 7:
Miyauchi, Hiroshi (The Sanno Institute ofManagement)
Ota, Mamoru (Enegate Co., Limited)
Sections 2, 4, and 5
Nakabayashi, Kiyoshi (NTT-Resonant Inc.)
Copyright
The Copyright of this document is owned by the e-Learning Consortium Japan (eLC),a non-profit organization.
The publication of this document was sponsored by the Japanese Ministry of
Economy and Industry for the purpose of promoting the SCORM 2004 standard.
The eLC (the Licensor) permits the other party (the Licensee) to copy, distribute,display or hyper-link this document under the following conditions:• The Licensee must acknowledge the Licensor explicitly by quoting the copyrightnotice and sponsorship statement above.
• The Licensee must not use this document for commercial purposes without
written permission from the Licensor.

121