This article will provide you, the developer, with a quick and simple understanding of what SCORM is and how it actually works. The most recent version of SCORM, SCORM 2004, will be discussed here; there is also a previous version of this article that references SCORM 1.2.
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.
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.
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.
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.
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 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.
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 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″>
<item identifier=”ITEM-2″ identifierref=”RES-2″>…
<item identifier=”ITEM-3″ identifierref=”RES-3″>…
<item identifier=”ITEM-4″ identifierref=”RES-4″>…
<imsss:randomizationControls selectCount=”1″ randomizationTiming=”onEachNewAttempt”/>