This article will provide you as a developer with a quick and simple understanding of what the SCORM is and how it actually works. As a consultant, I have worked on a number of projects helping companies conform their products to the SCORM. Whenever we get started, one of the first things I always do is give the developers a high-level overview of the SCORM and how it operates at a technical level. This knowledge helps to dispel some common misconceptions and allows us to begin architecting a solution that will ultimately be SCORM conformant.
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. The Run-Time Environment specifies how content should behave once it has been launched by the LMS. 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.
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.
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.
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.
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:
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.