Technical SCORM

A Technical Overview of the SCORM Standard

SCORM specifies that content should:

• Be packaged in a ZIP file.
• Be described in an XML file.
• Communicate via JavaScript.
• Sequence using rules in XML.

SCORM is composed of three sub-specifications

• The Content Packaging section specifies how content should be packaged and described. It is based primarily on XML.
• The Run-Time section specifies how content should be launched and how it communicates with the LMS. It is based primarily on ECMAScript (JavaScript).
• The Sequencing section specifies how the learner can navigate between parts of the course (SCOs). It is defined by a set of rules and attributes written in XML.

Content Packaging

The SCORM Content Aggregation Model (CAM) specifies that content should be packaged in a self-contained directory or a ZIP file. This delivery is called a Package Interchange File (PIF). The PIF must always contain an XML file named imsmanifest.xml (the “manifest file”) at the root. The manifest file contains all the information the LMS needs to deliver the content. The manifest divides the course into one or more parts called SCOs. SCOs can be combined into a tree structure that represents the course, known as the “activity tree”. The manifest contains an XML representation of the activity tree, information about how to launch each SCO and (optionally) metadata that describes the course and its parts.

More information on Content Packaging

Run-Time Environment

The run-time specification states that the LMS should launch content in a web browser, either in a new window or in a frameset. The LMS may only launch one SCO at a time. All content must be web deliverable and it is always launched in a web browser. Once the content is launched, it uses a well-defined algorithm to locate an ECMAScript (JavaScript) API that is provided by the LMS. This API has functions that permit the exchange of data with the LMS. The CMI data model provides a list of data elements (a vocabulary) that can be written to and read from the LMS. Some example data model elements include the status of the SCO (completed, passed, failed, etc), the score the learner achieved, a bookmark to track the learner’s location, and the total amount of time the learner spent in the SCO.

More information on the SCORM Run-time

Sequencing and Navigation

The sequencing specification allows the content author to govern how the learner is allowed to navigate between SCOs and how progress data is rolled up to the course level. Sequencing rules are represented by XML within the course’s manifest. Sequencing operates on a tracking model that closely parallels the CMI data reported by SCOs during run-time. Sequencing rules allow the content author to do things like:

• Determine which navigational controls the LMS should provide to the user (previous/next buttons, a navigable table of contents, etc).
• Specify that certain activities must be completed before others (prerequisites).
• Make some parts of a course count more than others toward a final status or score (creating optional sections or providing question weighting).
• Randomly select a different subset of available SCOs to be delivered on each new attempt (to enable test banking, for instance).
• Take the user back to instructional material that was not mastered (remediation).

More information on Sequencing and Navigation

Where does Rustici Software fit in to the picture?

As you’re starting to see, SCORM is a complicated standard to fully support. The time it takes to become SCORM conformant is generally measured in “developer years.” Our software solutions reduce this complexity dramatically. An LMS can become SCORM conformant with Rustici Engine in a matter of weeks, with full support (of the standard and our product.)