SCORM as Technical Framework for Web-based Learning

Schawn Thropp (attending)

U.S. Advanced Distributed Learning Initiative

ADL Liaison, CMI/SCORM WG, IEEE LTSC

ThroppS@ctcnsc.org

Tyde Richards

Chair, CMI/SCORM WG, IEEE LTSC

tyde_richards@us.ibm.com

Overview

The Sharable Content Object Reference Model (SCORM) is a technical framework for creating and deploying Web-based learning applications developed by the U.S. Government’s Advanced Distributed Learning Initiative (ADL – http://www.adlnet.org). SCORM provides a set of guidelines for integrating and applying specifications originally developed by the Aviation Industry CBT Committee (AICC – http://www.aicc.org), the IMS Global Learning Consortium (IMS – http://www.imsglobal.org) and the IEEE Learning Technology Standards Committee (IEEE LTSC – http://ltsc.ieee.org).

Introduced in 2000, SCORM has significantly evolved to the current SCORM 2004 release. ADL plans no additional features and is collaborating with the IEEE LTSC to standardize core SCORM capabilities. The IEEE LTSC anticipates constrained innovation to correct technical defects, to support diverse and global usage scenarios, and to harmonize the SCORM approach with established specifications and standards.

The key SCORM insight is to imagine the content used to deliver Web-based learning as composed of small, interoperable building blocks that may come from many different content providers, that may be implemented in different media types, and that may be selected and combined to support many different learning experiences. The name for one of these building blocks is a “Sharable Content Object” or SCO.

SCORM 2004 provides a set of core capabilities necessary to deliver an interoperable learning experience based on SCOs. These capabilities fall into the three categories of a Run-Time Environment (RTE), a Content Aggregation Model (CAM), Sequencing and Navigation (SN). Cumulatively, they enable a set of SCOs regardless of provenance or media type to be integrated into a unified experience in which the navigation requests or user information communicated by a SCO can invoke declarative sequencing rules that control the logical progression from one SCO to the next.

The classic SCORM usage scenario is an application known as a “learning management system” that relies on a run-time service distributed between a client and a server and that is considered as “owned” by the server. The relevance of SCORM to a workshop on client-side technologies is that the basic SCORM approach may also be used for client-side applications. Evidence for this comes from a predominantly client-side application known as “offline learning”.

SCORM 2004 Run-Time Environment

The SCORM 2004 RTE addresses the need for any SCO to have a standard means to exchange learner information with a run-time service used to support learning management. This entails that both SCO and run-time service share support for a communication mechanism to exchange information and share support for a data model for the actual information to be exchanged.

SCORM 2004 uses an IEEE standard for the communication mechanism to exchange information: IEEE 1484.11.2-2003 ECMAScript API for Content to Runtime Services Communication. This defines a small set of functions that allow a SCO to have a basic get-value/set-value data exchange with a run-time service. All requests are initiated by the SCO. An innovative feature of this approach is that the actual API implementation is not contained within the SCO but is provided by the run-time service and dynamically bound to the SCO when the SCO is delivered to the browser environment. This enables the same SCO to be used without modification with run-time service implementations having very different implementation strategies (e.g. client-server implementations using different transport mechanisms, client-side implementations). While this ECMAScript API standard was developed to support SCORM requirements it defines a generic capability that is in no way specific to learning applications and that may in fact have broad applicability.

SCORM 2004 uses a stable draft IEEE standard for the learner information exchanged between a SCO and run-time service: IEEE P1484.11.1 Data Model for Content Object Communication. The data elements in this data model are largely learning-specific but do support some more general capabilities. Among these are the ability for a user to suspend and resume interaction with a SCO with preservation of SCO-specific state information, the ability to indicate a maximum time and time limit action for experiencing a SCO, the ability to get and set location specific comments/annotations within a SCO.

There are two security concerns related to the SCORM 2004 RTE worth mentioning. The first is known as the “cross-domain scripting problem”. It occurs in a client-server implementation in which the domain supporting the run-time service and providing the API implementation is different from the domain providing the SCO. The result is a cross-domain security violation. While this problem is not relevant to a pure client-side implementation it is causing the IEEE LTSC to begin work on a Web service alternative, the message component of which may also have uses in client-side offline learning scenarios. The second security concern has to do with SCOs implemented with a “transparent” media format such as HTML or XML and susceptible to a “view source” action. This is a problem in learning applications if the learner can inspect the logic used to assess learner performance. For learning applications, some means to make transparent media “opaque” appears desirable.

SCORM 2004 Content Aggregation Model

The SCORM 2004 CAM addresses the problem of combining SCOs into a larger meaningful aggregate. At one level the CAM addresses the common problem of bundling together a set of resources into a compact format for purposes of exchange. The critical SCORM requirement is for an XML format that maps a representation of structured, contextualized learning activities into a set of context independent SCOs used to support those activities.

SCORM 2004 relies on the IMS Content Packaging specification for this capability. It essentially defines two trees. The first tree contains “items” in which each item may be augmented with meta-data to represent the specifics of a learning activity. The second tree contains “resources” in which each resource may be augmented with meta-data to represent the specifics of a SCO. Each resource may also represent a set of its constituent files and is therefore appropriate for representing Web content. Items (learning activities) reference their requisite resources (SCOs) The primary source for meta-data to transform generic items into learning activities and generic resources into SCOs is the IEEE 1484.12.1-2002 Learning Object Metadata standard.

The IEEE LTSC is in the planning phase of a standardization project to address the SCORM requirements for content aggregation. Investigation thus far reveals that the problem of relating organizing structure, meta-data and resource descriptions is a generic problem for which multiple similar solutions exist, each championed by particular communities of practice. For example, the ISO/IEC standard for MPEG 21.2 Digital Item Declaration is remarkably similar to IMS Content Packaging although developed completely independently. The probable IEEE LTSC approach will be to develop a logical model reflecting the core requirements of learning applications in the hope of promoting interchange between different approaches and some broadly applicable notion of conformance.

SCORM 2004 Sequencing and Navigation

The SCORM 2004 Sequencing and Navigation model is the newest and most complex part of SCORM and is described here in a simplistic way. It relies on the IMS Simple Sequencing specification and enables the precise declaration of the flow logic controlling the learner’s path from one SCO to the next. This is a necessary capability to support common instructional design strategies such as testing a learner’s understanding of a topic and appropriately directing the learner towards more complex or remedial material.

The model has a declarative component consisting of special sequencing meta-data added to learning activity nodes in the activity tree mentioned in the CAM discussion. The meta-data may indicate default navigation constraints such as only allowing the learner to navigate in a forward (next) direction or allowing the leaner to freely select any activity from a set of activities. The meta-data may also indicate sequencing rules in which a trigger such as an activity having been previously attempted or having its objective mastered can result in an action such as the activity being skipped or retried.

The model has a run-time component in which navigation requests and learner performance information communicated by a SCO are processed by a sequencing engine that evaluates the information in light of previously communicated performance information and the declared sequencing meta-data to determine the next SCO that will be delivered to the leaner.

SCORM 2004 introduces a small data model to allow a SCO to communicate navigation requests such as continue, previous, exit to a run-time service. This is as close as SCORM comes to addressing the problem of a standard set of user interface controls. An issue in combining SCOs from many different sources is known as the “ransom note” problem: potentially each SCO will have a different look and feel and approach to user interface controls. Solving this problem is perceived as important but also as extremely complex and difficult. If at some point a solution appears tractable, content providers, integrators, or consumer organizations may express a requirement to “brand” SCORM-based content with their particular look and feel.