SCORM 1.2 Overview for Developers

A technical guide to SCORM 1.2

This article will provide you, the developer, with a quick and simple understanding of the SCORM 1.2 eLearning standard and how it actually works.

This article references the most widely distributed version of SCORM- SCORM 1.2. An updated version that references SCORM 2004 is also available.

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 between government, academia and industry and it consolidates the work of AICC, IMS, ARIADNE and IEEE’s LTSC into one unified reference model.

Basically there are 2 parts SCORM Version 1.2: the Run-Time Environment and the Content Aggregation Model.

1. The Run-Time Environment specifies how content should behave once it has been launched by the LMS.
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.

The Run-Time Environment in a Nutshell

A SCORM conformant LMS is required to implement an API consisting of 8 Functions (see Section 3.3 of the SCORM Run-Time Environment document for full specification) that content may access to communicate with the LMS.

• LMSInitialize()
• LMSFinish()
• LMSGetValue()
• LMSSetValue()
• LMSCommit()
• LMSGetLastError()
• LMSGetErrorString()
• LMSGetDiagnostic()

This API is implemented by what the SCORM calls an API Adapter. An API Adapter must reside in a window that is an 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. The API Adapter must be an ECMAScript(JavaScript) object named “API” that is accessible though the DOM. The Adapter must implement the 8 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 LMSInitialize() when it starts and then call LMSFinish() 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 data model elements which the content can read from and write to, facilitating this kind of functionality (see Section 3.4 of the SCORM Run-Time Environment document for a full list of data model elements). LMSGetValue() retrieves a data model element’s value from the LMS, LMSSetValue() writes a value for a data model element to the LMS and LMSCommit() may be called after any values are set to ensure that the data is persisted.

For example:

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

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

strLastLocation = objAPI.LMSGetValue("cmi.core.lesson_location");

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

 blnSuccess = objAPI.LMSSetValue("cmi.core.lesson_location", "page3");
 blnSuccess = objAPI.LMSCommit("");

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 most 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 a Java applet, but others have been successful using Flash, ActiveX controls and pure JavaScript.

The Content Aggregation Model in a Nutshell

The Content Aggregation model is divided into three parts, the Content Model, the Meta-data and Content Packaging.

The Content Model describes the content being delivered. If the content contains more than one module, the content model describes any relationships between those modules (called Aggregations). 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 an enormous and 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 guidance that a SCO should represent the smallest unit of learning that the LMS should track. 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. See Section 2.1 of the SCORM specification for more information, many of the important details can also be found in Section 2.3 (Content Packaging).

The Meta-data specification provides a mechanism to describe the content using a pre-defined and common vocabulary. This vocabulary is broken into nine categories:

1. The General category groups the general information that describes the resource as a whole.
2. 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.
3. The Meta-metadata category groups information about the meta-data record itself (rather than the resource that the record describes).
4. The Technical category groups the technical requirements and characteristics of the resource.
5. The Educational category groups the educational and pedagogic characteristics of the resource.
6. The Rights category groups the intellectual property rights and conditions of use for the resource.
7. The Relation category groups features that define the relationship between this resource and other targeted resources.
8. The Annotation category provides comments on the educational use of the resource and information on when and by whom the comments were created.
9. The Classification category describes where this resource falls within a particular classification system.

The Meta-data specification defines a very rich data model, however only a small subset of the data elements are required to achieve SCORM conformance. The full Meta-data specification can be found in Section 2.2 of the SCORM Content Aggregation Model.

The Content Packaging specification defines how the Content Model and Meta-data are implemented. 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 PIF. At the root of this folder there must be an XML file called “imsmanifest.xml” which contains information from the Content Model and Meta-data specifications in a well-defined format. There are many good examples of Content Packaging available on the ADL website.

SCORM 1.2 Technical Summary

You now have a high-level overview of the SCORM 1.2 standard. From a technical perspective, the two most important things to take away are that

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 the SCORM will require a much more in-depth understanding of both the Run-Time Environment and the Content Aggregation Model.