A technical guide to SCORM 2004

This article will provide you, the developer, with a quick and simple understanding of  the SCORM 2004 eLearning standard and  how it actually works. There is a companion article that address the SCORM 1.2 standard available here.

The Sharable Content Object Reference Model (SCORM) allows learning content from any vendor to play in any SCORM-conformant Learning Management System (LMS). SCORM was created in cooperation among government, academia and industry, and it consolidates the work of AICC, IMS, ARIADNE and IEEE’s LTSC into one unified reference model.

There are three parts to SCORM 2004: the Run-Time Environment, the Content Aggregation Model and the Sequencing and Navigation specification.

  1. The Run-Time Environment specifies how content should behave once it has been launched by the LMS. Communication between the content and the LMS is handled by ECMAScript (JavaScript) in a web browser.
  2. The Content Aggregation Model specifies how you should package your content so that it can be imported into an LMS. This involves creating XML files that an LMS can read and learn everything it needs to know about your content
  3. The Sequencing and Navigation specification allows you to define rules that the LMS will use to control the learner’s navigation between sections of your content.

The Run-Time Environment in a Nutshell

In SCORM, all content is launched in a web browser. The LMS initiates the launch of the content and is required to implement an API consisting of eight functions that content may access to communicate with the LMS.

  • Initialize()
  • Terminate()
  • GetValue()
  • SetValue()
  • Commit()
  • GetLastError()
  • GetErrorString()
  • GetDiagnostic()

This API is implemented by what SCORM calls an API Adapter. The API Adapter must be an ECMAScript (JavaScript) object named “API_1484_11” that is accessible though the DOM. An API Adapter must reside in a window that is the opener window or a parent frame of the window that contains the content. This means that the LMS may launch the content either in a new window or in a frameset and the content will always know where to find this API. The Adapter must implement the eight functions listed above.

All communication between the content and the LMS is handled by this adapter, thus the content author does not need to worry about communicating with the server, he only needs to be able to find the API Adapter and make the appropriate JavaScript calls. This separation of client and server is essential to SCORM in that it ensures the portability of content by forcing it to run on a standard platform (the web browser). It is important to note that content can only communicate with the LMS through this JavaScript API Adapter. There is no SCORM-conformant method for content to communicate with the LMS through other methods such as web services, or HTTP requests.

For minimal SCORM conformance, the only thing that a piece of content needs to do is call Initialize() when it starts and then call Terminate() when it exits. It can be that simple.

In the real world, though, we want a much richer interaction. We want to be able to report test results, track time, bookmark our last location and more. This is where the next three functions come in to play. The SCORM defines a data model consisting of elements which the content can read from and write to, facilitating this kind of functionality. GetValue() retrieves a data model element’s value from the LMS. SetValue() writes a value for a data model element to the LMS and Commit() may be called after any values are set to ensure that the data is persisted.

For example:

cmi.location is the data element that describes the user’s location in the content

When the content begins (after it has called Initialize();), it may want to make this call to find out where the user left off and return him to that point:

 strLastLocation = objAPI.GetValue("cmi.location");

When the content goes to another area, it might make these calls to save the user’s location:

 blnSuccess = objAPI.SetValue("cmi.lesson_location", "page3");
 blnSuccess = objAPI.Commit("");

The other three functions allow the content to trap and intelligently deal with errors.

Implementing this API Adapter in the LMS is a little more involved than using it from content. The API Adapter has to implement all of the API functions and support all of the SCORM data model. The tricky issue involved with implementing a SCORM-conformant LMS is how to handle the browser-to-server communication. Many people choose to do this with AJAX, but others have been successful using Flash, ActiveX controls, Java applets and pure JavaScript.

Back to top

The Content Aggregation Model in a Nutshell

The Content Aggregation Model is divided into three sections, the Content Model, the Metadata and Content Packaging.

The Content Model section describes the content being delivered. If the content contains more than one module, the content model describes any relationships between those modules (called Aggregations). Aggregations can be nested to form a tree structure. The content model also describes the physical structure of the content (files needed, etc).

The Content Model defines a powerful model for breaking content into arbitrarily sized units of reuse. These units are called Sharable Content Objects (SCOs) and Assets. An Asset is simply an “electronic representation of media, text, images, sound, web pages, assessment objects or other pieces of data.” Examples of Assets include images, sound clips, Flash movies, etc. A SCO is a collection of one or more assets that represents a logical unit of learning.

The definition of a SCO is deliberately vague, it can be defined as a single web page or as a complex web-based training module containing hundreds of pages and hundreds more images and other assets. The definition of a SCO is left up to the content author to define under the guidline that a SCO should represent the smallest unit of learning that the LMS should track. Ideally, each SCO should be reusable. To achieve reuse, a SCO should not be context sensitive, it should not reference other SCOs, and it should not link to other SCOs. These considerations should be taken into account when determining the size of your SCOs.

The Metadata section provides a mechanism to describe the content using a pre-defined and common vocabulary. Any part of a SCORM course can be described by associated metadata. This vocabulary is broken into nine categories:

  • The General category groups the general information that describes the resource as a whole.
  • The Lifecycle category groups the features related to the history and current state of this resource and those who have affected this resource during its evolution.
  • The Meta-metadata category groups information about the metadata record itself (rather than the resource that the record describes).
  • The Technical category groups the technical requirements and characteristics of the resource.
  • The Educational category groups the educational and pedagogic characteristics of the resource.
  • The Rights category groups the intellectual property rights and conditions of use for the resource.
  • The Relation category groups features that define the relationship between this resource and other targeted resources.
  • The Annotation category provides comments on the educational use of the resource and information on when and by whom the comments were created.
  • The Classification category describes where this resource falls within a particular classification system.

The Metadata section defines a very rich data model, but its usage is completely optional in SCORM 2004. Content authors are allowed to define as much or as little metadata as is appropriate for their content.

The Content Packaging section defines how the Content Model and Metadata are implemented. The data structures described in the Content Model and Metadata are bound to a common XML format. All of the relevant data about the course is stored in an XML file named “imsmanifest.xml.” In order to facilitate smooth interoperability between systems, all content needs to be packaged in a similar manner. The Content Packaging specification requires all content to be transferred in a folder or a ZIP file called a “package interchange file (PIF)”. The “imsmanifest.xml” must be located at the root of the PIF.

Back to top

The Sequencing and Navigation Specification in a Nutshell

The Sequencing and Navigation specification governs how navigation between SCOs is handled by the LMS. It is not applicable to SCORM courses that consist of just one big SCO as it says nothing about how the navigation inside of a SCO should be handled. Navigation inside of a SCO is completely left to the discretion of the content developer, but the sequencing specification is necessary to allow developers of content chunked into SCOs to control the user experience. In sequencing, aggregations and SCOs are referred to by the generic term “activities.”

Content authors are able to specify sequencing rules via XML in the the course’s manifest. These rules (known as the “sequencing definition model”) can be broken down into the following categories:

  • Sequencing Control Modes – Determine what type of navigation is allowed by the user. Usually whether free navigation via a table of contents is used or whether linear navigation via previous/next buttons is used.
  • Constrain Choice Controls – Restrict the activities that the user may select from the table of contents.
  • Sequencing Rules – Specify if-then conditions that determine which activities are available for delivery and which activity should be delivered next.
  • Limit Conditions – Provide limits on the number of times activities can be attempted.
  • Rollup Rules – Specify if-then conditions that determine how status is rolled up through the hierarchy of aggregations.
  • Rollup Controls – Determine which activities participate in status rollup and how their status is weighted in relation to other activities.
  • Rollup Consideration Controls – Provide more precise control over status rollup than do the rollup controls.
  • Objectives – Provide a way to track the status of individual learning objectives and share this status across activities. Objectives are often overloaded and used as variables to control sequencing actions.
  • Selection Controls – Provide a way to specify that only a random subset of the available activities should be delivered.
  • Randomization Controls – Shuffle the order of the activities to be delivered.
  • Delivery Controls – Allow for non-communicative content to be delivered and sequenced.
  • Navigation Controls – Control which navigational UI elements should be presented by the LMS.

Sequencing operates on a “tracking model” that closely parallels a subset of the data model elements exchanged between the content and the LMS at run-time. When a SCO exits, the run-time data for the current SCO is transferred over to the sequencing tracking data. The LMS then invokes the “sequencing loop”. The sequencing loop is a set of defined algorithms that apply the sequencing rules to the current set of tracking data to determine which activity should be delivered next. These algorithms are well-defined in the sequencing specification by a set of pseudocode that the LMS’s behavior must mimic.

The XML below provides a simple sequencing example. In this example, Module 1 is an activity with three child activities (each represented by an item). In the sequencing for Module 1, the limit condition restricts this activity to two attempts. The rollup rule indicates that if at least one child has received a satisfied status, then Module 1 should be marked as completed. The randomization control indicates that on every new attempt of Module 1, one of its three child items should be selected at random for deliver.

<item identifier=”ITEM-1″ identifierref=”RES-1″>
<title>Module 1</title>
<item identifier=”ITEM-2″ identifierref=”RES-2″>…
<item identifier=”ITEM-3″ identifierref=”RES-3″>…
<item identifier=”ITEM-4″ identifierref=”RES-4″>…
<imsss:sequencing>
<imsss:limitConditions attemptLimit=”2″/>
<imsss:rollupRules>
<imsss:rollupRule minimumCount=”1″>
<imsss:rollupConditions>
<imsss:rollupCondition condition=”satisfied”/>
</imsss:rollupConditions>
<imsss:rollupAction action=”completed”/>
</imsss:rollupRule>
</imsss:rollupRules>
<imsss:randomizationControls selectCount=”1″ randomizationTiming=”onEachNewAttempt”/>
</imsss:sequencing>
</item>

Back to top

SCORM 2004 in summary

From a technical perspective, the two most important things to take away are:

  1. All communication between content and an LMS is handled via JavaScript
  2. All content should include an XML file called imsmanifest.xml which describes its structure and other characteristics to the LMS.

A full implementation of SCORM will require a much more in-depth understanding of both the Run-Time Environment and the Content Aggregation Model. This site should help you get started down the path.

Ready to implement SCORM but still have questions? Ask us anything.