SCORM 2004 Handbook

Version 1.04

March 2006

The e-Learning Consortium, JapanSCORM 2004 Handbook

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

iSCORM 2004 Handbook

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 Handbook

Table of ContentsDocument Revision History ...........................................................................................ii
Table of Contents ............................................................................................................i
1
Introduction............................................................................................................1
2
SCORM 2004 Overview........................................................................................2
2.1
What is SCORM? ..........................................................................................2
2.2
Origins of the SCORM Standard ...................................................................2
2.3
The LMS Model.............................................................................................3
2.4
SCORM 2004 Overview................................................................................3
2.5
Changes from SCORM 1.0 to SCORM 1.2...................................................5
2.6
Changes from SCORM 1.2 to SCORM 2004................................................62.6.1 Change to the Versioning of SCORM .......................................................62.6.2 Addition of the Sequencing Feature ..........................................................62.6.3 Triggering Navigation Requests from SCOs .............................................7
2.6.4 Changes to the SCORM Run-Time Environment .....................................7
2.6.5 Changes to the SCORM Content Aggregation Model...............................8
2.7
Future Evolution of SCORM .........................................................................93
Sequencing...........................................................................................................10
3.1
Content Structures and Learning Objectives ...............................................10
3.2
Tracking Information ...................................................................................123.2.1 Tracking Objective Status and Completion Status ..................................123.2.2 Information about Learning Time and Attempt Count ............................13
3.3
Navigation Requests, Sequencing Requests, and Termination Requests ....14
3.4
Sequencing Rules.........................................................................................16
3.4.1 Sequencing Control Modes......................................................................17
3.4.2 Limit Conditions ......................................................................................19
3.4.3 Precondition Sequencing Rules ...............................................................19
3.4.4 Post-Condition Rules and Exit Action Rules...........................................22
3.4.5 Rollup Rules.............................................................................................23
3.4.6 Local Objectives and Shared Global Objectives .....................................30
3.4.7 Shared Global Objectives and Rule Evaluations .....................................32
3.5
Attempts.......................................................................................................33
4
Navigation............................................................................................................34
4.1
Navigation Control Overview......................................................................34
4.1.1 SCO Navigation in SCORM 1.2..............................................................34
4.1.2 SCO Navigation in SCORM 2004...........................................................35
4.2
Triggering a Navigation Event and SCO Termination ................................35
4.2.1 SCO Navigation Event Triggered by an SCO .........................................35
4.2.2 Navigation Request Event and SCO Termination ...................................36
4.2.3 Validity of Navigation Request Events....................................................37
4.3
Controlling LMS-Provided Navigation Devices .........................................38
5
Run-Time Environment (RTE) ............................................................................40
5.1
SCORM 2004 Run-Time Environment Overview ......................................40
5.2
Launching Content Objects..........................................................................41
5.2.1 Assets .......................................................................................................41
5.2.2 SCOs ........................................................................................................41
5.3
API ...............................................................................................................42iSCORM 2004 Handbook
5.3.1 API Overview ..........................................................................................425.3.2 API Instance Overview ............................................................................425.3.3 Using the API Instance ............................................................................43
5.3.4 API Method Overview.............................................................................46
5.3.5 API Instance State Transitions.................................................................50
5.3.6 API Error Code Overview .......................................................................51
5.3.7 API Error Handler Implementation Example ..........................................55
5.4
Data Model...................................................................................................57
5.4.1 Data Model Overview..............................................................................57
5.4.2 Data Model Basics ...................................................................................57
5.4.3 SCORM Run-Time Environment Data Model ........................................62
5.4.4 Data Model Implementation Example .....................................................70
6
Sequencing Implementation.................................................................................74
6.1
Sequencing Process......................................................................................74
6.1.1 Navigation Process...................................................................................75
6.1.2 Termination Process.................................................................................75
6.1.3 Rollup Process .........................................................................................76
6.1.4 Selection and Randomization Process .....................................................77
6.1.5 Sequencing Process..................................................................................77
6.1.6 Delivery Process ......................................................................................78
6.2
Pseudo-Code ................................................................................................78
6.2.1 Overall Sequencing Process.....................................................................80
6.2.2 Termination Request Process...................................................................81
6.2.3 Sequencing Request Process....................................................................81
6.2.4 Flow Subprocess ......................................................................................82
6.2.5 End Attempt Process................................................................................82
6.2.6 Check Activity Process ............................................................................82
6.2.7 Sequencing Rule Check Process..............................................................82
7
Implementing the Run-Time Environment..........................................................83
7.1
Launch..........................................................................................................83
7.2
Implementing the API Instance ...................................................................85
7.3
Implementing Data Model Elements ...........................................................86
7.3.1 Data Model Elements Initialized by the LMS from Management Data ..86
7.3.2 Data Model Elements Initialized from the Manifest File ........................86
7.3.3 Data Model Elements with Fixed Values ................................................87
7.3.4 Read-only and Write-Only Data Model Elements Related to Each Other
87
7.3.5 Data Model Elements that Must be Preserved and Restored...................88
7.4
Tracking Model and RTE Data Model ........................................................90
7.4.1 Setting Information Regarding Activity Completion ..............................90
7.4.2 Setting Objective Progress Information for the Primary Objective.........91
7.4.3 Objective Progress Information for Objectives other than the Primary
Objective ..............................................................................................................93
7.5
Implementing the Navigation Function .......................................................938
Migration from SCORM 1.2 to SCORM 2004....................................................95
8.1
Differences in the Manifest File and Migration Methods............................95
8.2
Differences in the RTE and Migration.........................................................95
8.2.1 What Should Be Done on the LMS for RTE Migration ..........................96
8.2.2 What Should Be Done on SCOs for RTE Migration...............................97
Index.............................................................................................................................99ii

SCORM 2004 Handbook
About This Document.................................................................................................101iii

SCORM 2004 Handbookiv

SCORM 2004 Handbook

1 Introduction
The Sharable Content Object Reference Model (SCORM) has been used in Japan as
the standard for Web-based e-learning content and learning system development forover five years. During this time, learning management system (LMS) products,
content products and authoring tools that conform to SCORM have been widely used.
The SCORM standard that has generally been used so far is SCORM Version 1.2,
which was released in 2000. Although a large number of SCORM 1.2 compliant
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 the standard. The
purpose of this handbook is to provide a technical overview of this new standard aswell as an explanation of the newly added features and the differences from SCORM
1.2. The intended audience of this handbook consists of those who have someknowledge of SCORM.
SCORM 2004 introduces new sequencing and navigation features, and provides anentire range of detailed specifications. The new standard is expected to satisfy most of
the requirements expressed by the e-learning industry and the user community.
However, the technical content concerning SCORM 2004 exceeds some 800 pages inall, and the big picture cannot be easily understood from the individual technicalbooks. To assist those who have some knowledge of SCORM 1.2 and wish to learn
about SCORM 2004, this handbook gives an overview of the SCORM 2004 standard
and covers the newly added features and the differences from SCORM 1.2. Readers
should find it easier to understand the standard if they read this handbook first andthen scan through the standard books.
Section 2 gives an overview of SCORM 2004 with an emphasis on changes from theprevious version. Sections 3 and 4 cover the newly introduced sequencing andnavigation features. These two sections provide an overview of the new features andexplain areas that may be difficult to understand. Section 5 covers the SCORM 2004
Run-Time Environment with an emphasis on the differences from SCORM 1.2.
Sections 6 and 7 explain how to implement the sequencing feature and a runtime
environment from the standpoint of LMS implementers. Section 8 covers points to be
noted when migrating from SCORM 1.2 to SCORM 2004.
The SCORM 2004 technical books and their acronyms that this handbook uses asreferences are listed below.
OV: SCORM 2004 2nd Edition Overview
CAM: SCORM Content Aggregation Model Version 1.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

1SCORM 2004 Handbook

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

2

SCORM 2004 Handbook

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.

3

SCORM 2004 Handbook(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.

4

SCORM 2004 Handbook

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.

5

SCORM 2004 Handbook
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.

6

SCORM 2004 Handbook

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 Changes
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 Changes
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.

7

SCORM 2004 Handbook
•
•

•
•
•

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.

8

SCORM 2004 Handbook

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.

9

SCORM 2004 Handbook

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

10

SCORM 2004 Handbook
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

Termination & 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.

11

SCORM 2004 Handbook

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.

12

SCORM 2004 Handbook
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.

13

SCORM 2004 Handbook
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.

14

SCORM 2004 Handbook

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

15

SCORM 2004 Handbook

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.

16

SCORM 2004 Handbook

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.

17

SCORM 2004 Handbook
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).

18

SCORM 2004 Handbook
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
Currenta)b)

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].

19

SCORM 2004 Handbook

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.

20

SCORM 2004 Handbook

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.

21

SCORM 2004 Handbook

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.

22

SCORM 2004 Handbook
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 the23

SCORM 2004 Handbook
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 × ObjectiveNormalizedMeasure)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:

24

SCORM 2004 Handbook(1) Using the 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.
25

SCORM 2004 Handbook
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.

26

SCORM 2004 Handbook►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

27

SCORM 2004 Handbook
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

•
•

28

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

29

SCORM 2004 Handbook

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.

30

SCORM 2004 Handbook

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.

31

SCORM 2004 Handbook

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,

32

SCORM 2004 Handbook
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.2

Leaf activity currently being attempted

A1.2
A1.2.1Figure 3.6 Attempts

33

SCORM 2004 Handbook

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 an LMS.
Different navigation interfaces dependingon the LMS.
Menu Frame

No navigation control
for another SCO wasallowed in an SCO

Displayed byLMS

SCO Frame

API FrameSCO

API Adapter

Figure 4.1 Example of SCOM 1.2 Navigation Implementation

34

SCORM 2004 Handbook

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 Frame
SCO
An SCO can
implement SCO
navigation controls.

API Frame

API Instance

Figure 4.2 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.

35

SCORM 2004 Handbook
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.
36

SCORM 2004 Handbook

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 Example of Using 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.

37

SCORM 2004 Handbook
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>

38

SCORM 2004 Handbook

Without hideLMSUI specified

With hideLMSUI specified

Figure 4.4 Displaying and Hiding LMS-provided Navigation Devices

39

SCORM 2004 Handbook

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).

40

SCORM 2004 Handbook

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.

41

SCORM 2004 Handbook

SCO1.2

SCO1.1

Not Allowed to Launch another SCO

LaunchAPI Instance(Provided by LMS)LMS

Web browser

Figure 5.2 Launching an 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.

42

SCORM 2004 Handbook

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 Instance43

SCORM 2004 Handbook
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.
Below is a sample code for searching recursively for the API Instance.

44

SCORM 2004 Handbook<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() {// Find an API frame.
if ((window.parent != null) && (window.parent != window)) {API = FindAPI(window.parent);}// Find the API Instance in an opener window.
if ((API == null) && (window.opener != null)) {API = FindAPI(window.opener);}
if (API != null) {// Initialize
API.Initialize("");} else {alert("Cannot find the API Instance。");}}
function MyFin() {if (API != null) {// Terminate the session
API.Terminate("");
}
}
//-->
</script></head><body onload=”MyInit();” onunoad=”MyFin()”><h1>SCORM Sample Code</h1></body></html>45

SCORM 2004 Handbook

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

46

SCORM 2004 Handbook
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.

47

SCORM 2004 Handbook

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.

48

SCORM 2004 Handbook

CommitGetLastError

GetErrorString

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.
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.
49

SCORM 2004 Handbook

GetDiagnostic

Support Methods
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• TerminatedRunning

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()50

SCORM 2004 Handbook• 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
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 Category
Error Code Range Description
No Error0
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 specificpurposes
Table 5.5 shows the details of the API implementation errors.
51

SCORM 2004 Handbook

Code
0
101
102

103

104

111
112
113

122

123

132

133

Table 5.5 API Error Code Details
Description
This 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.
Termination
The SCO attempted to terminate
After
the communication session afterTermination
the communication session was
successfully terminated.
Retrieve Data
The SCO attempted to retrieve
Beforedata before it successfully
Initialization initialized a communication
session.
Retrieve Data
The SCO attempted to retrieve
Afterdata after termination of the
Termination
corresponding communication
session.
Store Data
The SCO invoked a SetValue
Beforemethod of the API Instance toInitialization store data before it successfully
initialized a communication
session.
Store Data
The SCO invoked a SetValue
Aftermethod of the API Instance toTermination
store data after termination of
the corresponding
communication session.
Message
No Error52

API Methods
All methods
Initialize()

Initialize()

Initialize()

Initialize()

Terminate()

Terminate()

Terminate()

GetValue()

GetValue()

SetValue()

SetValue()SCORM 2004 Handbook
Code
142

MessageCommit Before
Initialization

143

Commit After
Termination

201

GeneralArgument Error

301

General Get
Failure351

General Set
Failure391

General Commit
Failure401

Undefined Data
Model Element

Description
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.
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.

53

API Methods
Commit()Commit()Initialize()
Terminate()
Commit()GetValue()

SetValue()

Commit()GetValue()
SetValue()SCORM 2004 Handbook
Code
402

Message
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

408

Data Model
Dependency Not
Established

Description
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.
This error code is designed forhandling 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.

54

API Methods
GetValue()
SetValue()

GetValue()

SetValue()

GetValue()

SetValue()

SetValue()

GetValue()
SetValue()SCORM 2004 Handbook
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 Type5.3.7 API Error Handler Implementation Example
An SCO should contain an API implementation error handler that can check andinterpret the error code set by the API Instance at each state transition.
An example of code that can be used to check error states is shown below.

55

SCORM 2004 Handbook<html><head><script type=”text/javascript”><!-var API = null;function FindAPI(win) {(Omitted)}function MyInit() {(Omitted)}function MyFin() {(Omitted)}//----- Check errors----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 Sample Code</h1></body></html>56

SCORM 2004 Handbook

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.

57

SCORM 2004 Handbook

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. Refer to Section 7.4 for the
relationships between tracking information and the RTE Data Model.
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 of58

SCORM 2004 Handbook
objectives currently stored for the SCO, the following API method call would be
used:
var 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.

59

SCORM 2004 Handbook

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}鈴木 一郎

60

SCORM 2004 Handbook(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.

61

SCORM 2004 Handbook
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.

62

SCORM 2004 Handbook
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 attempt63

SCORM 2004 Handbook

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

64

SCORM 2004 Handbook

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

65

SCORM 2004 Handbook

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

66

SCORM 2004 Handbook

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

67

SCORM 2004 Handbook

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

68

SCORM 2004 Handbook

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

69

SCORM 2004 Handbook

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

5.4.4 Data Model Implementation Example
The SCORM Run-Time Data Model is a collection of data model elements that areused between the LMS and SCOs. Both the LMS and SCOs communicate under theassumption that each party knows about these data model elements. The major
communication behaviors include:• Initialization• Read data
• Write data
• Save / Store
5.4.4.1 Read-only Examples(1) Description Examples
Example 1) Learner’s ID
id = GetValue(“cmi.learner_id”);

Example 2) SCO’s launch data
Lpm = getValue(“cmi.launch_data”);

70

SCORM 2004 Handbook
Example 3) Maximum time allowed with the SCO
Time_limit = getValue(“cmi_max_time_allowed”);(2) Behavior• The LMS performs initialization using the session data and the information
regarding the associated activity tree.
• The SCO utilizes this information after retrieving it from the Run-Time
Environment.
• The SCO cannot update the values of these data elements.
(3) Description• The initial value for Example 1) above is provided from the session information
managed by the LMS.
• The initial values for Examples 2) and 3) are the values defined in the manifest
file (imsmanifest.xml) as follows:
Example 2) Initialized with the value defined for <adlcp:dataFromLMS>,
which is the launch data for the SCO.
Example 3) Initialized with the value defined for<imsss:attemptAbsoluteDurationLimit>, which indicates thelearning time allowed for the learner on the SCO.
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 5.6 Getting Data Model Element Values
5.4.4.2 Write-only Examples(1) Description Example
Example 4) Session time
SetValue(“cmi.session_time”, “05:15:00”);(2) Behavior• The LMS does not initialize.
• The SCO sets a value to the specified data model element.
71

SCORM 2004 Handbook• The LMS processes, saves and stores the information.
(3) Description• 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 5.7 Setting Data Model Element Values
5.4.4.3 Read and Write Examples(1) Description Example
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”);(2) Behavior• 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.
(3) Description• The data model elements used for reading and writing are those used to get 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.

72

SCORM 2004 Handbook

Update the success status with
SetValue(“cmi.success_status”, “passed”);

The LMS initializes the data
model elements as “unknown”

SCO

LM

Manifest fileLearner’s
interaction
Retrieves the success status value with
GetValue(“cmi.success_status”)

Figure 5.8 Getting and Setting Data Model Element Values

73

SCORM 2004 Handbook

6 Sequencing Implementation
This section describes sequencing behaviors and their implementation methods. The
sequencing behavior model is implemented by a set of procedures called sequencing
processes. A request is passed between the sequencing processes, and a sequencing
process is described by pseudo-code. An overview of the processing represented inthis pseudo-code is given in this section.

6.1 Sequencing Process
As shown in Figure 3.1, the sequencing behavior is implemented through a set ofprocedures called sequencing processes. Although the SCORM SN book uses theterm “behavior”, this document has been standardized with the term “process”. Figure
6.1 shows the relationship between these processes.
Wait for navigation request

Navigation Request

Navigation Process
Termination Request, Sequencing Request
Termination Process

OverallSequencing
Process

Rollup Process

Select and Randomize Process
Sequencing Request
Sequencing Process
Delivery Request
Tracking Data

Delivery Process

Figure 6.1 Overall Sequencing Process
The sequencing behavior model is implemented through the overall sequencing
process. The overall sequencing process starts with a navigation request from thelearner’s Web browser, determines the next activity to be delivered to the Webbrowser, and then waits for the next navigation request and repeats this action.
A navigation request is sent from the Web browser. The navigation process judges
whether the navigation request is valid, and generates a termination request and asequencing request as explained in Section 3.3.

74

SCORM 2004 Handbook
The termination process that handles the generated termination request performs suchactions as terminating the activity, terminating the whole learning process or
suspending the process. After terminating the activity and determining the necessary
tracking information, the termination process calls the rollup process that updates the
tracking information for the entire activity tree based on the specified rollup rules.
After the rollup, defined post-condition rules (if any) are evaluated, and if theconditions are satisfied, the sequencing request from the learner is transformed intoanother sequencing request.
After this, the selection and randomization process changes the order of activities tobe presented if required.
The sequencing request is then passed to the sequencing process which decides thenext activity to be delivered. The sequencing process applies different subprocesses,
depending on each sequencing request, to determine the next activity to be delivered
for the learner by evaluating sequencing control modes, limit conditions andprecondition rules, among other things.
Finally, the information concerning the activity that has been identified for delivery ispassed to the delivery process as a delivery request. The delivery process reconfirms
the limit condition and precondition rules for the activity, initializes the datanecessary for tracking the activity, and then delivers the activity.
Each component process of the overall sequencing process may refer to or update thetracking information. The SCO in the Web browser updates the tracking information
for the associated leaf activity through the Run-Time Environment. Conversely, theSCO in the Web browser can refer to its own tracking information regarding theassociated leaf activity. The rollup process updates the tracking information for theentire activity tree based on the tracking information collected from the related leaf
activities. The termination process, the sequencing process and the delivery processevaluate the sequencing rules and limit conditions by referring to the tracking
information updated by the rollup process.

6.1.1 Navigation Process
The navigation process waits for a navigation request from the learner’s Web browser,
and generates a termination request and a sequencing request when it receives arequest, as explained in Section 3.3. The navigation process ignores irrelevant
navigation requests like a start navigation request when the learning process is alreadyin progress. In the other cases, the navigation process transforms the navigation
request into a termination request and a sequencing request as explained in Section
3.3.

6.1.2 Termination Process
The termination process receives a termination request from the navigation process,and terminates the current activity. Depending on the type of termination request, it
performs one of the following termination actions:• Exit, Exit All: The values of the run-time data model elements for the SCO arereflected in the tracking information for the associated activity. The current
75

SCORM 2004 Handbook
activity is terminated. In the case of an Exit All termination request, the wholelearning process is terminated.
• Abandon, Abandon All: The values of the run-time data model elements for the
SCO are not reflected in the tracking information for the associated activity. The
current activity is terminated. In the case of an Abandon All termination request,
the whole learning process is terminated.
• Suspend All: The current activity and all its ancestral activities are suspended. A
suspended activity can be resumed with a Resume All sequencing request. The
attempt in this case is not a new one but a continuation of the attempt interrupted
by the suspension.
In the case of an Exit termination request, the termination process performs thefollowing actions:(1) The termination process terminates the current activity, and reflects the values of
the Run-Time Environment Data Model elements managed by the SCO during
the run-time in the tracking information for the associated activity. If the learning
resource associated with the activity is an asset which does not send run timeenvironment information, the LMS sets the default tracking information.
(2) It calls the rollup process, which is explained in the next section.
(3) It evaluates the termination rules and post-condition rules. If the parent activity is
to be terminated with an Exit Parent or Exit All rule, it recursively evaluates thetermination rules and post-condition rules for the parent activity. When asequencing request is generated as a result of a Continue, Previous or Retry rule
being applied, the termination process replaces the sequencing request from thenavigation process with this sequencing request.

6.1.3 Rollup Process
During the rollup process, the measure rollup, objective rollup and progress statusrollup actions are performed. See Section 3.4.5 for the details of these actions.
(1) In the measure rollup, the normalized objective measure for a parent activity is
calculated from the weighted values of the measures for the primary objectives of
its child activities.
(2) In the objective rollup process, the objective status of a parent activity’s primaryobjective is determined using one of the methods described below. When 1) isapplied, the other methods are not applied, and if 2) is applied then 3) is notapplied.
1) Compare the objective measure computed by the measure rollup processagainst the predefined threshold value.
2) Apply the defined rollup rules.
3) Apply the default rollup rules.
(3) In the progress status rollup process, the attempt completion status for a parent
activity is determined using one of the following methods: When 1) is applied, 2)
is not applied.
1) Apply the defined rollup rules.
2) Apply the default rollup rules.

76

SCORM 2004 Handbook

6.1.4 Selection and Randomization Process
The selection and randomization process defines how the child activities of a cluster
are selected for presentation to the learner and how the activities are re-ordered forpresentation to the learner.
(1) In the selection process, a specified number of candidate activities are selectedfrom among the child activities of a cluster for presentation to the learner. The
selection is done when an attempt is made for the first time on the associatedcluster.
(2) In the randomization process, the order of presentation for more than one child
activity included in a cluster is changed at random. It is possible to specify
whether randomization is performed at the first attempt on the cluster or at eachnew attempt.

6.1.5 Sequencing Process
The sequencing process receives a sequencing request from the navigation process,and determines the next activity to be presented to the learner based on theinformation in the request. The sequencing process consists of a number of specificprocesses corresponding to the types of sequencing request. Each process applies
sequencing control modes, limit conditions and precondition rules when it determines
the next activity to be delivered.
6.1.5.1 Activity Decision Processing Overview
Processes to select the activity to be delivered can be categorized depending on thetypes of sequencing request.
(1) Launch: Start, Resume All and Choice
These sequencing requests are processed for the start of a learning experiencefrom a state where no current activity has been identified. For a Start sequencing
request, the Flow subprocess (explained below) traverses the target activity tree todetermine the next activity to be delivered. For a Resume All sequencing request,
the learning experience is resumed from the activity that was previously
suspended. For a Choice sequencing request, a selected activity is delivered forthe learner.
(2) Activity Tree Traversal: Continue, Previous and Choice
For these sequencing requests, a target activity is determined by traversing theassociated activity tree forward (Continue) or backward (Previous). The Flow
subprocess is applied to the traversal of the activity tree. For a Choice sequencing
request, the selected activity becomes the destination of the movement. If a nonleaf activity is selected, then a target activity is determined by applying the Flow
subprocess to the cluster consisting of the selected activity and its descendantactivities.
(3) Retry
For a Retry sequencing request, the current activity is again selected for delivery
to the learner. If a non-leaf activity is specified in this case, then a target leaf
activity is determined by applying the Flow subprocess.
(4) Exit
For an Exit sequencing request, the current attempt on the activity is terminated. If
the current activity is the root of an activity tree, the sequencing session ends.

77

SCORM 2004 Handbook
6.1.5.2 Flow Subprocess Overview
The Flow subprocess traverses an activity tree from a designated activity in a
specified direction to select an activity to be delivered next. A candidate activity to bedelivered to the learner is a leaf activity, and if it cannot reach a leaf activity, the Flow
subprocess returns an error. Below is an outline of the behavior of the Flow
subprocess:(1) It moves to the next activity in the activity tree from the current activity in adesignated direction, and that activity becomes the candidate activity.
(2) If the Sequencing Control Flow of the candidate’s parent activity is evaluatedas false, then it treats it as an error and terminates the sequencing process.
(3) If the Skip precondition rule for the candidate activity is evaluated as true, thenit moves from the candidate to another activity in the designated direction,
selects that activity as a candidate, and returns to (2) above.
(4) If the Disable precondition rule or the limit condition for the candidate activity
is evaluated as true, then it raises an error state and terminates the sequencing
process.
(5) If the candidate is a leaf activity, then it selects this as the next activity to bedelivered, and terminates the sequencing process.
(6) If the candidate is not a leaf activity, it enters the cluster and selects a
candidate.
In the case of forward traversal, the first child activity of the cluster becomes acandidate.
In the case of backward traversal where the Sequencing Control Forward Only
is false, the last child activity of the cluster becomes a candidate.
In the case of backward traversal where the Sequencing Control Forward Only
is true, the first child activity of the cluster becomes a candidate.

6.1.6 Delivery Process
The delivery process receives a delivery request for the candidate activity that has
been selected through the sequencing process, and delivers the activity to the clientside. During the delivery process, whether the limit conditions are violated is checked
for that candidate activity and all its ancestral activities. An attempt on the activity isthen started and the logging of the elapsed time for the activity and other data is
started as well.
The actual learning resource, an SCO or asset, is delivered using the launch process of
the Run-Time Environment.

6.2 Pseudo-CodeSCORM 2004 provides a precise specification for the behaviors of the component
processes that constitute the overall sequencing process. This section describes therelationships between these process calls and provides an overview of their actions.
Tables 6.1 and 6.2 show the relationships between process calls. Table 6.1 shows therelationships between process calls used in the overall sequencing process. The
processes that are called from more than one place are highlighted in bold letters.
These processes are explained in detail in Table 6.2. The numbers in a pair of square

78

SCORM 2004 Handbook
brackets are the process identification codes used in the pseudo-codes of the standard
specifications.
A summary of the major processes is given below.

79

SCORM 2004 Handbook
Table 6.1 Pseudo-Code Process Call Relationships
Overall Sequencing Process [OP.1]
Navigation Request Process[NB.2.1 ]Termination Request Process[TB.2.3 ]End Attempt Process [UP.4]
Sequencing Exit Action Rules Subprocess[TB.2.1 ]Sequencing Rules Check Process [UP.2]
Terminate Descendent Attempts Process [UP.3]
End Attempt Process [UP.4]
Sequencing Post Condition Rules Subprocess[TB.2.2 ]Sequencing Rules Check Process [UP.2]
Terminate Descendent Attempts Process [UP.3]
Select Children Process [SR. 1]
Randomize Children Process [SR.2]
Sequencing Request Process[SB.2.12 ]Start Sequencing Request Process[SB.2.5 ]Flow Subprocess [SB.2.3 ]Resume All Sequencing Request Process[SB.2.6 ]Exit Sequencing Request Process[SB.2.11 ]Retry Sequencing Request Process[SB.2.10 ]Flow Subprocess [SB.2.3 ]Continue Sequencing Request Process[SB.2.7 ]Flow Subprocess [SB.2.3 ]Previous Sequencing Request Process[SB.2.8 ]Flow Subprocess [SB.2.3 ]Choice Sequencing Request Process[SB.2.9 ]Sequencing Rules Check Process [UP.2]
Choice Activity Traversal Subprocess[SB.2.4 ]Sequencing Rules Check Process [UP.2]
Choice Flow Subprocess [SB.2.9.1]
Choice Flow Tree Traversal Subprocess[SB.2.9.2 ]Choice Flow T ree Traversal Subprocess[SB.2.9.2 ] REC
Flow Subprocess [SB.2.3 ]Terminate Descendent Attempts Process [UP.3]
Delivery Request Process [DB.1. 1]
Check Activity Process [UP.5]
Content Delivery Environment Process[DB.2 ]
Clear Suspended Activity Subprocess[]
DB.2.1
Terminate Descendent Attempts Process [UP.3]

6.2.1 Overall Sequencing ProcessThis is the process that covers the entire set of sequencing behaviors. The processes
making up the overall process are called in sequence to perform the actions discussed
in Section 6.1. That is, the sequencing actions are performed by calling, one after
another, the Navigation Request Process, the Termination Request Process, the SelectChildren Process, the Randomize Children Process, the Sequencing Request Process,the Delivery Request Process and the Content Delivery Environment Process.

80

SCORM 2004 Handbook
Table 6.2 Pseudo-Code Process Call relationships (Subprocesses)
Flow Subprocess [SB.2.3 ]Flow Tree Traversal Subprocess [SB.2.1 ]Flow Tree Traversal Subprocess [SB.2.1 ] REC
Flow Activity Traversal Subprocess [SB.2.2 ]Sequencing Rules Check Process [UP.2]
Flow Tree Traversal Subprocess [SB.2.1 ]Flow Activity Traversal Subprocess [SB.2.2 ] REC
Check Activity Process [UP.5]
Terminate Descendent Attempts Process
End Attempt Process [UP.4][UP.3]End Attempt Process [UP.4]
Overall Rollup Process [RB.1. 5]
Measure Rollup Process [RB.1.1 ]Objective Rollup Process [RB.1.2 ]Objective Rollup Using Measure Process [RB.1.2 a]
Objective Rollup Using Rules Process [RB.1.2 b]
Rollup Rule Check Subprocess [RB.1.4 ]Activity Progress Rollup Process[RB.1.3 ]Rollup Rule Check Subprocess [RB.1.4 ]Rollup Rule Check Subprocess [RB.1.4 ]Check Child for Rollup Subprocess[RB.1.4.2 ]Sequencing Rules Check Process [UP.2]
Evaluate Rollup Conditions Subprocess[RB.1.4.1 ]Check Activity Process [UP.5]
Sequencing Rules Check Process [UP.2]
Limit Conditions Check Process[UP.1 ]
Sequencing Rules Check Process [UP.2]
Sequencing Rule Check Subprocess[UP.2.1 ]6.2.2 Termination Request Process
The Termination Request Process processes termination requests. It consists of the
End Attempt Process, which ends the attempt on the current activity and performs
rollup, the Sequencing Exit Action Rules Subprocess, which processes the exit rules,
the Sequencing Post Condition Rules Subprocess, which processes post-condition
rules, and the Terminate Descendent Attempts Process, which performs thetermination of the ancestral activities of the current activity.

6.2.3 Sequencing Request Process
Depending on the received sequencing request, a specific process is called from thefollowing sequencing request subprocesses: Resume All, Exit, Retry, Continue,81

SCORM 2004 Handbook
Previous and Choice. Among these processes, the Start, Retry, Continue, andPrevious sequencing request subprocesses apply the Flow Subprocess for an activity
tree traversal to select the activity to be delivered.
In the case of the Choice sequencing request subprocess, it is possible to determine
whether the candidate is valid for delivery by applying a specific traversal, dependingon the relationship between the current activity and the activity tree containing thecandidate activity.

6.2.4 Flow Subprocess
The Flow subprocess determines a candidate activity for delivery by traversing theactivity tree forward or backward. Its internal structure is designed in such a way that
the Flow Tree Traversal Subprocess and the Flow Activity Traversal Subprocess arerecursively called. In the Flow Tree Traversal Subprocess, the activity next to thecurrent activity in the designated direction becomes a candidate without theprecondition rules and others being checked. In the Flow Activity Traversal
Subprocess, the precondition rules and other conditions are evaluated for the
candidate activity determined by the Flow Tree Traversal Subprocess, and whether
the candidate is valid for delivery is checked. If the Skip precondition rules areevaluated as true, the Flow Tree Traversal Subprocess and the Flow Activity
Traversal Subprocess are recursively called in the traversal of the activity tree.

6.2.5 End Attempt Process
The End Attempt Process performs the end processing of the activity. Specifically,
when the activity is a leaf activity and there is no SCO associated with the activity,
the tracking information for the activity is reset with default values. The overall
sequencing process is called and rollup is performed. In the Overall Rollup Process,the Measure Rollup Process, the Objective Rollup Process and the Activity Progress
Rollup Process are called to perform, respectively, measure rollup, objective rollup
and progress rollup actions.

6.2.6 Check Activity Process
The Check Activity Process checks the limit conditions, the Disable precondition rules
and other conditions for the activity, and confirms whether the activity is valid fordelivery.

6.2.7 Sequencing Rule Check ProcessThis process checks whether the condition clause of a sequencing rule is evaluated as
true.

82

SCORM 2004 Handbook

7 Implementing the Run-Time Environment
As discussed in Section 5, SCORM specifies the Run-Time Environment forcommunication between the LMS and SCOs. This section describes how to
implement the SCORM Run-Time Environment, and the points to be noted during theimplementation, from the LMS implementer’s standpoint. This section explains how
to implement the launching and ending process of an SCO, how to implement an API
Instance, and then how to deal with both SCORM 1.2 compliant SCOs and SCORM
2004 compliant SCOs. In addition, it discusses the points to be noted in
implementing the RTE Data Model elements, the relationships between the data
model elements and attempts, and data retention issues for handling attempts that aresuspended and then resumed, and so on. This section also covers the relationship ofsequencing with tracking information, and then discusses the points to be noted in
implementing the navigation function.

7.1 Launch
In the launch process, the LMS selects a learning resource to be delivered to thelearner and launches it. If the delivered resource is an SCO, the SCO searches for the
API Instance that is provided by the LMS, and maintains a communication session
with the LMS using the API Instance. This subsection explains a sample
implementation of an LMS to deal with this process.
Figure 7.1 shows a screenshot of a Web browser through which a learner is studying
under a SCORM compliant LMS. In this example, the browser screen is divided into
three frames. A set of command buttons for issuing navigation requests is located in
the Menu frame (top). What is displayed in this frame varies depending on the LMS.
The SCO frame (middle) displays the learning resource. What is displayed in thisframe is the learning resource itself. The bottom frame is where the API Instance islocated, and the size of this frame is set to 0 so that learners cannot see it.

The Menu Frame

The Menu

The SCO FrameSCO

The API Frame

The API Instance

Figure 7.1 Frame Composition of a Client Window
The LMS implements the launching process by assigning an API Instance on the Webbrowser and sending the designated resource to the Web browser. This is done by83

SCORM 2004 Handbook
sending an HTML file in which the three frames are defined. An example of such an
HTML file is shown below:<HTML><HEAD><TITLE>LMS system</TITLE><SCRIPT LANGUAGE ="JavaScript">function myOnLoad( url ){ self.Main.location = url; }</SCRIPT></HEAD>(1)<FRAMESET ROWS=“100%,0%” onLoad = myOnLoad(“sco_url")><FRAMESET ROWS="43,*"><FRAME NAME=“Menu” SRC=“menu_generation_url"><FRAME NAME="Main" SRC="about:blank"></FRAMESET><FRAME NAME=“API_1484_11” SRC=“api_instance_url"></FRAMESET>

(2)
(3)
(4)
(5)

</HTML>As shown in (2) and (3) above, the menu frame (name: Menu), the SCO frame (name:
SCO) and the API Instance frame (name: API_1484_11) are defined. Note that themenu frame and the SCO frame are defined as one step deeper than the API Instanceframe. This is because the SCO has to search for the API Instance starting from its
parent frame as explained in Section 5.3.3.
There is an important point to be noted in this HTML definition. The SCO frame isinitially left blank in (4), and when the frame is loaded, the onLoad event is triggered
and thus myOnLoad function (1) is invoked to actually download the SCO. If the
URL of the SCO is directly specified in (4) without using this mechanism, whether
the SCO or the API Instance will be downloaded to the Web browser first is uncertain.
If the SCO is downloaded first and starts searching for the API Instance, the SCO may
fail to find the API Instance. As this is a timing-related problem, it will be very
difficult to detect because such a problem may occur on some Web browsers but not
on others. To prevent such a problem, the onLoad event (2) is used in the above
HTML definition to invoke the myOnLoad function (1), which will actually download
the SCO. As the onLoad event is triggered after the frameset definition has been
completely interpreted, the SCO is always downloaded (1) only after the API Instance(5) has been downloaded. Figure 7.2 shows this temporal relationship.

84

SCORM 2004 Handbook
LMS(1) A navigation button like “Next” is pressed.
(2) Defines three frames: menu, blank for SCO,
and hidden API Instance frame.
(3) Requests the menu and the API(4) Responds to the menu frame.
(5) Responds to the API(6) Loads menu and the API
Instance(7) The SCO calls the FindAPI().

Frame set
Menu

API
SCO

Figure 7.2 Temporal Relationships at SCO Launching Time

7.2 Implementing the API InstanceAn API Instance is implemented in the form of a DOM object. In this DOM object,
the API methods are defined in the ECMAScript language, which is generally known
as JavaScript. The only requirement specified in the standard for an API
implementation is that it enable communication of the run-time data model elements
to the LMS using the API methods specified in the standard. The other details are left
to the implementers of specific LMS products. For example, it is not specified in thestandard whether the values of the data model elements should be kept on the client or
the server. In general, the simplest solution may be to keep the business logic forhandling data elements only on the server rather than on the client, but when thesystem performance is considered important, it may be better to allow the client tomanage data model elements as much as possible from the viewpoint ofcommunication volume and the server processing load.
The standard specifies that the API Instance be named “API_1484_11”. However, thename was “API” in SCORM 1.2. By taking advantage of this difference, it is possible
to make both SCORM 1.2 compliant and SCORM 2004 compliant SCOs run under a
SCORM 2004 compliant LMS. Figure 7.3 shows how this can be done. In thisexample, the LMS provides two separate API Instances under the names of“API_1484_11” and “API”. As a SCORM 2004 compliant SCO will use the former
API Instance while a SCORM 1.2 compliant SCO will use the latter API Instance,
there is no need for the SCOs to be conscious of the difference in API method names
and data model element names between SCORM 2004 and SCORM 1.2. The
SCORM 1.2 API Instance is implemented in such a way that the run time data model
elements and API methods of SCORM 1.2 are converted to those of SCORM 2004.
Refer to Section 8 for details.

85

SCORM 2004 Handbook

SCO

1.2 SCO

API
Instance“API”

2004 SCO
Conversion between SCORM 1.2 and SCORM 2004

“API_1484_11 ”
SCORM 2004 API Instance

SCORM 2004 LMS
Figure 7.3 Running both SCORM 1.2 and SCORM 2004 SCOs undera SCORM 2004 LMS

7.3 Implementing Data Model Elements
From the viewpoint of an SCO, the data model elements provided in the Run-Time
Environment have three modes of communication direction: read-only, write-only andread / write. Among these data model elements, most of the read-only data model
elements are initialized by the LMS from the management data and the information
provided in the manifest file so that SCOs can use them. Therefore, the LMS must
initialize these. There are data model elements that are not currently used but containfixed values. In the case of read / write data model elements, the LMS should preserve
the values set by the SCOs, and return the values when the SCOs request them.
However, caution is required as some data model elements are related to the tracking
model in sequencing. This section explains the data model elements that requirecaution when they are implemented.

7.3.1 Data Model Elements Initialized by the LMS fromManagement Data
The cmi.learner_id and cmi.learner_name data model elements are read-only
elements, and they are initialized from management data. In general, as it manages the
IDs and names of learners, the LMS makes this information available for SCOs toretrieve through the initialization of the above data model elements.

7.3.2 Data Model Elements Initialized from the Manifest File
The following data model elements are read-only elements and are initialized from thevalues specified in the manifest file: cmi.completion_threshold, cmi.launch_data,
cmi.max_time_allowed, cmi_scaled_passing_score and cmi.time_limit_action. Table
7.1 shows this correspondence. If an SCO attempts to retrieve the value of a data
model element whose value is not specified in the manifest file, an error is raised with“403 – Data Model Element Value Not Initialized.”86

SCORM 2004 Handbook

Table 7.1 Data Model Elements Initialized from the Manifest File
Data Model Element Name
Description
Manifest Element NameThreshold performance measure forcmi.completion_thresholddetermining the completion of the SCO<adlcp:completionThreshold>Initialization parameters for launching the
cmi.launch_data
SCO<adlcp:dataFromLMS>
The maximum amount of accumulated
cmi.max_time_allowed
time allowed for one attempt on the SCO<imsss:attemptAbsoluteDurationLimit>
The scaled passing score required to be
cmi.scaled_passing_scoreconsidered to have mastered the SCO<imsss:minNormalizedMeasure>
The action to be taken by the SCO when
cmi.time_limit.action
the max_time_allowed value is reached<adlcp:timeLimitAction>

7.3.3 Data Model Elements with Fixed Values
An LMS is required to implement cmi.credit and cmi.mode as read-only data model
elements. However, the uses of these elements are not specified. It will be sufficient
to set “credit” and “normal” to these data model elements, respectively.

7.3.4 Read-only and Write-Only Data Model Elements Related toEach Other
The cmi.session_time and cmi.total_time pair and the cmi.exit and cmi.entry pair ofdata model elements are each write-only and read-only element pairs, but the valuesof the read-only data model elements are affected by the values of the write-only data
model elements.
The cmi.session_time data model element represents the elapsed session time from thelaunching of the SCO, and the cmi.total_time data model element represents the totalsum of a learner’s session times on the SCO. The LMS sums the values of the last
cmi.session_time data model elements reported from the launching of an SCO until its
termination, and sets the value to the cmi.total_time data model element. If a
cmi.session_time value is reported during a session, it will be ignored by the LMS.
The initial value of the cmi.total_time is 0.
The cmi.exit data model element represents information regarding how and why thelearner left the SCO, and the cmi.entry data model element indicates the exit status of
the SCO in the previous attempt. The initial value of cmi.entry is “ab_initio”; theLMS sets the value of cmi.entry to “resume” if the cmi.exit value is “suspend” or“logout”, and sets it to “” if the value of cmi.exit is “normal” or “time-out”.
When an attempt is resumed (Resume All) after it was suspended (Suspend All), thecmi.total_time and cmi.entry data model elements should reflect the values prior to theinterruption. Therefore, the LMS should store the values of cmi.total_time andcmi.entry using a persistent file or other means for each SCO, and restore them at thetime when the attempt is resumed.

87

SCORM 2004 Handbook

7.3.5 Data Model Elements that Must be Preserved and Restored
The following data model elements are read / write type elements: cmi.location,
cmi.suspend_data, cmi.interactions, cmi.learner_preference, cmi.score,
cmi.progress_measure, cmi.objectives, cmi.completion_status, and cmi.success_status.
The LMS must ensure that the values of these data model elements set by an SCO arepreserved so that they can be retrieved at a later stage. If a learner has suspended an
attempt on an SCO, the LMS must store the values prior to the interruption using apersistent file or other means so that those values can be restored when the attempt isresumed.
For cmi.location, cmi.suspend_data and cmi.interactions, it is necessary to ensure thatthe values set by the SCO are allowed to be retrieved as they are. The LMS should notprocess these data elements. If the value of one of these data elements is queried
before the SCO writes a value to it, an error is raised with “403 – Data Model Element
Value Not Initialized.”
The cmi.learner_preference data model element is a read / write element for keeping
the learner’s specific preferences, such as the language that the learner will use, thevolume of the speakers and so on, with the SCO. This element may be initialized by
the LMS using the management data, and then may be updated by the learner during alearning session. If the LMS does not maintain relevant management data, a specificdefault value to each data model element is set.
In addition, for cmi.score, cmi.progress_measure, and cmi.objectives, it is necessary
to ensure that the values set by the SCO are allowed to be retrieved as they are. The
LMS should not process these data elements. If the value of one of these data
elements is queried before the SCO writes a value to it, an error is raised with “403 –Data Model Element Value Not Initialized.”
The values of the cmi.completion_status and cmi.success_status data model elements
are used as reported by the SCO. The initial values of the elements are “Unknown”,
but the LMS may determine their values by comparing the values of
cmi.progress_measure and cmi.score_scaled against the values defined in the
manifest file (adlcp:completionThreshold and imsss:minNormalizedMeasure).
Tables 7.2 and 7.3 respectively show the rules for determining the values of
cmi.completion_status and cmi.success_status.

88

SCORM 2004 Handbook
Table 7.2 Determining the Completion Status
Manifest’s
cmi.progress_
cmi.completion_
cmi.completion_
adlcp:completionmeasurestatusstatusset by SCO
set by SCO
set by LMS
Threshold =cmi.completion_
thresholdunknown
unknown
unknown
unknown
Value by SCO
unknown
unknown
Token（Note）
unknown
0.5
unknown
unknown
Token
Value by SCO
unknown
0.5
0.8
unknown
unknown
unknown
Token
Value by SCO
0.8
unknown
0.8
0.5
unknown
incompleteTokenincomplete
0.8
0.5
0.8
0.9
unknowncompleted
Token
0.8
0.9
completed
Note: One of the three vocabulary tokens: completed, incomplete, or
not attempted
Manifest’s

Table 7.3 Determining the Success Status
cmi.score.
cmi.success_stat
scaledus

imsss:minNormalized
set by SCO
set by SCO
Measure =cmi.scaled_passing_score
unknown
unknown
unknown
unknown
unknown
Token（Note）
unknown
0.5
unknownToken
unknown
0.5
0.8
unknown
unknown
Token
0.8
unknown
0.8
0.5
unknown
Token
0.8
0.5
0.8
0.9
unknown
Token
0.8
0.9
Note: One of the two vocabulary tokens: passed or failed

cmi.success_status
set by LMS

unknown
Value by SCO
unknown
Value by SCO
unknown
Value by SCO
failedfailedpassedpassedThe basic way to determine the completion status is as follows:• If the cmi.progress_measure value is greater than or equal to the
cmi_completion_threshold value, the status is completed. The value reported by
the SCO for cmi.completion_status is ignored.
• If the cmi.progress_measure value is smaller than the cmi_completion_thresholdvalue, the status is incomplete. The value reported by the SCO for
cmi.completion_status is ignored.
• If either the cmi.progress_measure value or the cmi_completion_threshold value
is unknown, the completion status is determined by the value reported by the SCO
for cmi.completion_status.

89

SCORM 2004 Handbook
The value of cmi.success_status is determined in a similar way by giving a higher
priority to the comparison of the cmi.score_scaled value against the
cmi.scaled_passing_score value. If one of the data model element values is unknown,
the value reported by the SCO is applied.
By taking advantage of this behavior to determine the success status, it is possible tochange the conditions for passing by associating one SCO with more than one activity
and then specifying different passing scores for these activities within the manifest
file.
Note that the cmi.completion_status, cmi.success_status, cmi.score.scaled,
cmi.progress_measure, cmi.objectives.n.success_status, andcmi.objectives.n.score.scaled data model elements are related to the tracking
information for the sequencing function. These are explained in the next section.

7.4 Tracking Model and RTE Data Model
For the Tracking Model elements described in Section 3.2, the information about thecompletion of a leaf activity and the objective progress information is set by using
RTE Data Model elements. If the learning resource associated with an activity is anasset rather than an SCO, the LMS sets pre-determined values to these elements.

7.4.1 Setting Information Regarding Activity Completion
Table 7.4 shows the correspondence between the Tracking Model elements and the
RTE Data Model elements related to the completion of an activity.
The value of the Attempt Completion Status element is determined by the value of
cmi.completion_status. The value of cmi.completion_status is generally set with avalue reported by the SCO, but as was discussed in a previous section, caution isrequired because the cmi.completion_status value is sometimes determined by the
LMS by comparing the value of cmi.progress_measure against that ofcmi.completion_threshold.
As the value of cmi.completion_status will not be set when the learning resource
associated with the current activity is an asset rather than an SCO, the LMS
sometimes automatically sets the value of cmi.completion_status to “completed”. The
LMS displays this behavior under the following conditions:• If the Tracked element of the activity is set to True, and• If the Completion Set by Content element is set to False, and• If the value of cmi.completion_status is Unknown.
Although Attempt Completion Amount and cmi.progress_measure are defined asdata model elements, these are not currently used in sequencing and theirrelationship is not specified.

90

SCORM 2004 Handbook

Table 7.4 Tracking Model and RTE Data Model Elements for Attempt Completion
RTE Data Model Elements
Tracking Model Elements
cmi.completion_status
Attempt Completion Statuscompleted (Initial value for assets)completedincomplete
incomplete
not attempted
incomplete
unknown (Initial value)
unknown
Note: See Table 7.2 for how to determine the value of cmi.completion_status.
cmi.progress_measureAttempt Completion Amount[0..1][0..1]
unknown (Initial value)
unknown
Note that SCORM 2004 does not use Attempt Completion Amount for sequencing,and it does not specify the relationship of this Tracking Model element with
Progress Measure.

7.4.2 Setting Objective Progress Information for the Primary
Objective
Table 7.5 shows the correspondence between the Tracking Model and the RTE Data
Model elements.
The progress information about an objective is managed with the Objective Progress
Status and Objective Normalized Measure elements. In the case of the primaryobjective, these values are determined by the values of cmi.success_status andcmi.score.scaled. In principle, the values of these RTE Data Model elements arehonored as they are reported by each SCO; however, as shown in Table 7.3, the valueof cmi.success_status is sometimes determined by the LMS by comparing the
cmi.score_scaled value against the cmi.scaled_passing_score value.
As the value of cmi.success_status will not be set when the learning resource
associated with the current activity is an asset rather than an SCO, the LMS may
sometimes automatically set the value to “completed”. The LMS displays thisbehavior under the following conditions:• If the Tracked element of the activity is set to True, and• If the Objective Set by Content element is set to False, and• If the value of cmi.success_status is Unknown.
Table 7.5 Tracking Model and RTE Data Model Elements
for Progress Information about the Primary Objective
RTE Data Model Elements
Tracking Model Elements
cmi.success_status
Objective Satisfied Status
passedsatisfiedfailednot satisfied
unknown (Initial value)
unknown
cmi.score_scaled

Objective Normalized Measure[-1..1]
unknown[-1..1]
unknown (Initial value)91

SCORM 2004 Handbook
Note: Refer to Table 7.3 for how to determine the value of cmi.success_status.

92

SCORM 2004 Handbook

7.4.3 Objective Progress Information for Objectives other than thePrimary Objective
The Objective Satisfied Status element values for other objectives are determined by
cmi.objectives.n.success_status and the Objective Normalized Measure values are
determined by cmi.objectives.n.score_scaled. Between
cmi.objectives.n.success_status and cmi.objectives.n.score_scaled in this case,however, there is no dependency relationship as there is with cmi.success_status andcmi.score.scaled for the primary objective. For these objectives, furthermore, theLMS does not perform an automatic initialization even if the resource associated withthe activity is an asset. The value of cmi.objectives.n.id that can be retrieved by an
SCO is an ID (Activity Objective ID) assigned to a local objective for the activity.
When a local objective is connected to a shared global objective in such a way that the
local objective reads the value of the shared global objective, the values of
cmi.objectives.n.success_status and cmi.objectives.n.score.scaled that the SCO canretrieve are the same as those of the Objective Satisfied Status and Objective
Normalized Measure for the shared global objective. On the other hand, when a local
objective is connected to a shared global objective in such a way that the local
objective writes the value of the shared global objective, the values of
cmi.objectives.n.success_status and cmi.objectives.n.score.scaled that the SCO will
send are reflected in the values of the Objective Satisfied Status and Objective
Normalized Measure for the shared global objective.
Table 7.6 Tracking Model and RTE Data Model Elements for Objective Progress
Information for Objectives other than the Primary Objective
RTE Data Model Elements
Tracking Model Elements
cmi.objectives.n.success_status
Objective Satisfied Status
passedsatisfiedfailednot satisfied
unknown(Initial value)
unknown
cmi.objectives.n.score_scaled
Objective Normalized Measure[-1..1][-1..1]
unknown (Initial value)
unknown
cmi.objectives.n.id
Activity Objective ID
Universal Resource Identifier
Unique identifier

7.5 Implementing the Navigation Function
As explained in Section 4, SCORM 2004 allows an SCO to trigger navigation events.
The SCO can trigger a navigation event by calling the RTE API method
SetValue(“adl.nav.request”, <REQUEST>). If the SCO invokes the Terminate(“”)
method after that, the LMS processes the navigation request indicated by<REQUEST>. Although the SCO can invoke SetValue(“adl.nav.request”,<REQUEST>) any number of times, the LMS ignores all the calls except the one
immediately before the Terminate(“”) API method call. The <REQUEST> in theabove SetValue function call must be one of the following: “continue”, “previous”,“choice”, “exit”, “exitAll”, “abandon”, “abandonAll” or “_none”. If the last93

SCORM 2004 Handbook
navigation request before the Terminate(“”) method is the one with “_none”, theLMS does not do anything.
Navigation events are triggered not only by SCOs but also by the navigation userinterface devices provided by the LMS. For this reason, there can be a situation wherea navigation event triggered by the SCO is in competition with one triggered by a userinterface device provided by the LMS. In this case, the navigation event triggered by
the LMS-provided user interface device is always selected for processing with ahigher priority.
Suppose an SCO has invoked the SetValue(“adl.nav.request”, ”continue”) method
call and then the learner has chosen another SCO from the menu displayed by the
LMS with a “choice” navigation request. In this case, the new SCO is loaded onto the
Web browser and the old SCO is unloaded. As an SCO generally calls the
Terminate(“”) API method at the unload event, the “continue” navigation event thatwas triggered earlier competes with the “choice” navigation request triggered by thelearner. In this case, the LMS gives priority to the navigation event issued by thelearner and ignores the “continue” navigation event.

94

SCORM 2004 Handbook

8 Migration from SCORM 1.2 to SCORM 2004
Compared with SCORM 1.2, SCORM 2004 has added sequencing and navigation
features and introduces a more detailed specification. This section describes thedifferences between the two and how to convert contents to the new standard.

8.1 Differences in the Manifest File and Migration Methods
In 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 or navigation rule definitions.
Note, however, that a special caution is required as the following SCORM 1.2
elements have been deprecated in SCORM 2004:•••

adlcp:prerequisites
adlcp:masteryscore
adlcp:maxtimeallowed

The adlcp:prerequisites data model element for an activity was previously defined asa logical expression with the completion status and progress status information ofanother activity to determine whether a candidate activity was valid for the learner.
Such a condition could be defined in SCORM 1.2, but there was no specification as to
how the LMS should behave for the possible results of the condition, and this caused
interoperability problems. As the behavior of each LMS implementation was notpredictable under the previous version, it is necessary to convert the value of this data
model element into a set of sequencing rules as designed by the content developer
when converting content to SCORM 2004.
The adlcp:masteryscore and adlcp:maxtimeallowed data model elements are replaced
in SCORM 2004 with imsss:minNormalizedMeasure andimsss:attemptAbsoluteDurationLimit, respectively. The values of these elements canbe referred to by an SCO during the run-time via the Run-Time Environment. The
corresponding RTE data model elements are cmi.scaled_passing_score andcmi.max_time_allowed.
SCORM 1.2 compliant Manifest files that do not contain adlcp:prerequisites,
adlcp:masteryscore or adlcp:maxtimeallowed definitions can be used under a
SCORM 2004 compliant LMS without change. It is also possible to take advantage ofthe new features of SCORM 2004 by adding sequencing rules into such manifest files
as required. The cost of converting manifest files to SCORM 2004 is not expected tobe very high.

8.2 Differences in the RTE and Migration
As explained in Section 5, the new Run-Time Environment (RTE) specifications are
not compatible with their predecessor as there have been considerable changes madeto the name of the API Instance, the API method names, data model elements and so
95

SCORM 2004 Handbook
on. To run SCORM 1.2 compliant SCOs in a SCORM 2004 compliant environment,
the SCOs must be modified as required by the changes. The amount of necessary
modification is expected to be so large that this may create a bottleneck in the whole
migration process.
The following subsections describe the measures to be taken on the LMS side to avoid
such a bottleneck. At the same time, SCORM 1.2 compliant LMS products and
SCORM 2004 compliant products are expected to coexist for some time in the future.
Measures that can be taken on the SCO side to cope with such a situation are also
discussed below.

8.2.1 What Should Be Done on the LMS for RTE Migration
To enable SCORM 1.2 compliant SCOs to run in a SCORM 2004 environment, the
LMS can take advantage of the difference in the names of the API Instance as
explained in Section 7.2. The DOM object name for the SCORM 1.2 API Instance is“API” and that for the SCORM 2004 API Instance is “API_1484_11”. Thus, aSCORM 1.2 compliant SCO searches for an API Instance called “API”, while a
SCORM 2004 compliant SCO searches for an API Instance called “API_1484_11”.
SCORM 1.2 content can be enabled to run in a SCORM 2004 environment by taking
advantage of this difference in names.
To deal with this difference, the LMS can be implemented in such a way that itprovides two API Instances under the names of “API” and “API_1484_11” as shownin Figure 7.3. The API Instance named “API” exposes the RTE API methods of
SCORM 1.2 while the API Instance named “API_1484_11” exposes the RTE API
methods of SCORM 2004. As the SCOs of the two different standards will thensearch for an appropriate API Instance and make correct API method calls, there will
be no need to change the SCOs.
The SCORM 1.2 API Instance mentioned above should be implemented in such a
way that it internally translates the data model element names and error codes
between the two SCORM versions. As most of the data model elements arecompatible between the two versions, except for a few name changes, it is possible tomap one set to another without change. As the cmi.score.lesson_status SCORM 1.2
data model element is expanded to cmi.completion.status and cmi.success_status in
SCORM 2004, however, it is necessary to add a conversion rule for handling thisdifference. Tables 8.1 and 8.2 show examples of the rules for handling such
conversions. The same conversion method can be applied for the
cmi.objectives.n.status SCORM 1.2 data model element and the
cmi.objectives.n.completion.status and cmi.objectives.n.success_status SCORM 2004
data model elements. Note also that cmi.score.scaled andcmi.objectives.n.score.scaled are newly added in SCORM 2004. Such a measure isneeded to ensure that appropriate values are set to these elements from an SCO that
affect sequencing. SCORM 1.2 did not have data model elements corresponding tothese new elements, but assigning the respective normalized values of
cmi.core.score.raw and cmi.objective.n.score.raw to the new data model elements is
considered appropriate. Note that the conversion rules mentioned above are notdefined in the standard, and LMS implementers will have to incorporate them as
required.
96

SCORM 2004 Handbook

8.2.2 What Should Be Done on SCOs for RTE Migration
The fact that SCORM 2004 has been released as a new standard does not mean thatall LMS products will automatically be converted to the standard, and SCORM 1.2
compliant and SCORM 2004 compliant LMS products are expected to coexist for awhile. For this reason, it is desirable to develop content in a way that allows it to run
under both LMS environments.
Table 8.1 Converting Progress Status Data from SCORM 1.2 to SCORM 2004
SCORM 1.2
SCORM 2004
cmi.core.lesson_status
cmi.completion_status
cmi.success_status
unknown
unknown
unknown
passedcompletedpassedfailedincomplete
failedcompletedcompletedunknown
incomplete
incomplete
unknownbrowsedincomplete
unknown
not attempted
unknown
unknown
Table 8.2 Converting Progress Status Data from SCORM 2004 to SCORM 1.2
SCORM 1.2
SCORM 2004
cmi.core.lesson_status
cmi.completion_status
cmi.success_status
 unknown
unknown
unknown unknownpassedpassed unknown
failedfailed completedcompletedunknown
 completedpassedpassed completed
failedfailed incomplete
incomplete
unknown
 incomplete
passedpassed incomplete
failedfailedFigure 8.1 shows how to implement such an SCO. The SCO is equipped with a virtual
API that deals with the two API Instances. The virtual API determines whether thecurrent environment conforms to SCORM 1.2 or SCORM 2004, and then invokes
appropriate API methods for the SCO and performs data model element conversion.
To determine the version of the current Run-Time Environment, for example, theSCO searches for its API Instance, first using the name “API_1484_11” and then thename “API”, and then determines from the name of the found API Instance whether itruns in a SCORM 1.2 environment or a SCORM 2004 environment.
For the translation of API method calls and data model elements between the twostandards, the virtual API provides the SCO with functions corresponding to the RTE
API methods so that when these functions are called, they are translated into theircorresponding API methods of the current Run-Time Environment.

97

SCORM 2004 Handbook

SCO-specific Part

SCO

Virtual API
RTE Version
Determination“API”“API_1484_11”

SCORM 1.2 LMSSCORM 2004 LMS

LMS
Figure 8.1 Implementing an SCO for both SCORM 1.2 and SCORM 2004

98

SCORM 2004 Handbook

Index
Objective, 10
Objective measure rollup, 24
Objective rollup, 24
Overall sequencing process, 74, 80
Post condition rules, 22
Precondition sequencing rules, 19
Primary objective, 10, 11, 23, 24, 25,
27, 32, 76, 91, 93
Progress rollup, 25
Pseudo Code, 78
real, 61
Rollup, 23
Rollup process, 76
Rollup rules, 23, 26
RTE, 4, 40, 83, 95
RTE data model, 57, 62, 70
RTE data model elements, 57
RTE migration, 97
Run-time environment, 83
SCO, 41, 43
SCORM, 2
SCORM 1.0, 5
SCORM 1.1, 5
SCORM 1.2, 6, 97
SCORM 2004, 3
SCORM 2004 Overview, 4
SCORM run-time environment, 40
SCORM Run-Time Environment, 4
SCORM run-time environment data
model, 57
SCORM Sequencing and Navigation, 4
SCO's navigation event, 35
Selection and randomization process,77
Sequencing, 10, 74
Sequencing conrol Choice Exit, 18
Sequencing control Choice, 17Sequencing control Flow, 17
Sequencing control Forward Only, 18
Sequencing control modes, 17
Sequencing process, 74
Sequencing request, 14
Sequencing request process, 77, 81
Sequencing rules, 16
Sequencing rull check process, 82
Sharable Content Object (SCO), 41

Activity, 10
Activity tree, 10
API, 42
API adapter, 42
API error codes, 51
API error handler, 55
API instance, 42, 50, 85, 95
API instance state transition, 50
API methods, 46, 95
Asset, 41
Attempt, 33
CAM, 4
Changes from SCORM 1.2, 6
characterstring, 60
Cluster, 10Content Aggregation Model, 4Content structure, 10
Data model, 70
Data model elements, 7, 57, 64, 86
Data model extension, 62
Data types, 60
Delivery process, 78
DOM, 44ECMAScript, 44
End attempt process, 82
Exit action rules, 22
Flow subprocess, 78, 82
integer, 61
language type, 61
Launching, 83
Launching learning resources, 41
Leaf activity, 10
Limit condition, 19
LMS, 43
LMS model, 3
LMS-provided navigation devices, 38
localized string type, 60
long identifier type, 61
Manifest file, 4, 6, 7, 10, 38, 64, 66, 67,
68, 70, 71, 86, 88, 90, 95
Navigation, 34
Navigation control, 34
Navigation function, 93
Navigation process, 75
Navigation request, 14
Navigation request event, 36

99

SCORM 2004 Handbook
Tracking data, 12
Tracking model, 90
Tracking model and RTE data model,
90
Tree structure, 10
Use Current Attempt Objective
Information, 18
Use Current Attempt Progress
Information, 18

Sharable Content Object Reference
Model, 2, 5
short identifier type, 61
state, 61
Termination process, 75
Termination request, 14
Termination request process, 81
time, 61
timeinterval, 61

100

SCORM 2004 Handbook

About This Document
Acknowledgements
This document was a translation of a Japanese document authored by the following
people:Sections 1, 3, and 6 – 9:Sections 2, 4, and 5

Nakabayashi, Kiyoshi (NTT-Resonant Inc.)
Miyauchi, Hiroshi (The Sanno Institute ofManagement)
Ota, Mamoru (Enegate Co., Limited)

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.

101