On this page:
The SCORM 2004 content object communication data model is based on an IEEE standard: IEEE 1484.11.1-2004. A companion IEEE standard, 1484.11.3-2005, specifies an XML schema for that data model. LMS or other application developers who wish to use XML can use that standard schema. This document is a brief overview of the standard and how it relates to the SCORM CMI data model. The document also discusses applications of the schema for reporting or for specialized applications.
The SCORM 2004 "CMI" data model is used for communication between a SCORM content object (SCO, or Sharable Content Object) and the runtime environment provided by a learning management system to deliver the SCO to a learner. In SCORM, this data model is called CMI for historical reasons going back to an older AICC specification. The SCORM 2004 CMI data model is an implementation of an IEEE standard with the long title of IEEE Standard 1484.11.1-2004 IEEE Standard for Learning Technology-Data Model for Content Object Communication. This standard defines an "abstract" data model. In other words, that data model can be implemented in various ways, such as for example a database schema, an XML schema or, in the case of the SCORM CMI implementation, using a dot notation. Another IEEE standard defines an XML schema for the same data model. It is not currently used in SCORM, for reasons explained below, but it can be extremely useful for all kinds of implementations such as communication between the client side of a runtime environment and its server-side support services, for archiving SCORM tracking data in an implementation-independent format, and for data mining and report generation that does not depend on a proprietary database's implementation.
The dot notation used in SCORM for SCO communication breaks down the data model and data instances into discrete elements for individual transmission. The dot notation was used for historical reasons. One is that the AICC had developed a working dot notation to represent the AICC's similar data model. The other reason was that SCORM was and is intended to be deployed on any mainstream web browser without requiring proprietary plug-ins or add-ons in the content. At the time of the CMI model specification, XML was not a practical solution for wide scale deployment in web browsers because of lack of widespread built-in support for XML. Nowadays most web browsers that implement ECMAScript also support DOM (Document Object Model) functions and XML natively, but SCORM continues to use the dot notation to avoid disruption.
The dot notation used in SCORM works. It allows content developers with little or no understanding of DOM and XML to use the SCORM API through simple calls. As we saw above, at one point there was no choice since ECMAScript implementations did not support the DOM and XML. However, the dot notation has several major disadvantages. One is that, for every data element or fragment of a data structure, getting or setting a value requires a call to the API. This is not a big problem in the communication between a SCO and the client side of a runtime environment, because this is handled in real time by a fast local ECMAScript call. However, it can cause a huge performance problem if every call has to be made via a remote procedure call through the Internet in real time, or needs to to be handled by a separate database query.
Another major disadvantage of the dot notation is that it requires the introduction of data artifacts that cause various problems. For example, whereas in a database table each row can be indexed by a unique identifier, or in an XML document the sequence of records can define their order the dot notation requires on artificial index numbers to define ordering and to be able to address each record. Those index numbers don't exist in the value space or in the data model, but you can't use the dot notation without using them. Because these are indexes in an array, the array operations are artificially constrained. For example, you cannot delete a record since that would create a discontinuity in the index.
Finally, the dot notation is cumbersome because in order to exploit the data in a CMI data instance you must first convert the dot notation elements and values into some other binding, such as structured data objects or relational tables. For example, where it is relatively easy to generate a human readable report from an XML document using XSLT, it is much more cumbersome to do so by using data in dot notation because you need to collect it from some proprietary data storage.
XML allows the "batching" of any number of data elements in a single document that can be transmitted or passed to a service for processing with a single call. If you build an application that processes CMI data, like for example a SCORM runtime environment, you may find XML useful as a way to minimize network traffic and facilitate processing. For example, you can use the DOM (document object model) facilities supported by all modern browsers to manage the XML document. You can then use XMLHTTP on the client side and SOAP on the server side, and by using the XML binding you can easily exchange blocks of data between the client and the server sides of your runtime environment.
In order to represent the CMI data model in XML, it is necessary to consider the original IEEE standard for the data model. Where a CMI data instance is overloaded with dot notation artifacts, the relevant information must be translated into the XML equivalent, using the abstract data model standard as a guide. Fortunately, this is not difficult.
For example, the CMI data model array "cmi.objectives", which is an unordered collection of objective information records in the IEEE standard, can be represented in XML by an "objectives" element that contains a collection of objective information record elements. "cmi.objectives.1.success_status" can be translated in the XML instance into a success status child of an objective information element, without worrying about the 1 which is just an ordinal index.
In developing the IEEE standard XML schema, making such translations to and from the CMI dot notation easy and straightforward was an important consideration. The IEEE standard document contains a detailed informative annex that documents, element by element, how the data model is represented in the XML schema.
There is however one issue which is already familiar to many LMS implementers. Some of the string values transmitted through the SCORM API may contain unsafe characters or other characters that may cause problem in an XML document. For those data elements, the strings must either be escaped or enclosed in a CDATA block within the XML element.
The IEEE standard XML schema was also designed to facilitate exploitation and serialization through various techniques. For example, one can write a XSL document that, when applied through XSLT, generates the ECMAScript statements necessary to generate fully populated data structures and arrays that map exactly to the CMI dot notation.
The IEEE standard XML schema was designed to help facilitate a straightforward remapping of the data into relational data tables and into structured data object types while faithfully representing the IEEE standard data model. In particular, the schema and namespace were built to support reuse of fragments of the IEEE standard XML schema, by exposing most data type and element definitions as "top level" components in the namespace. For example, instead of creating a new subschema for "objectives" information, you can simply reference the IEEE standard XML schema namespace and reuse the existing data type or element definition.
The data model contains both ordered and unordered collections. This distinction cannot always be represented in an XML schema. Where the XML Schema 1.0 specification does not allow an unambiguous binding of such collections, the IEEE schema includes machine readable, informative notation in the form of an attribute named "collectionType".
The data model specifies SPM values for various elements (see the SCORM Runtime Environment book for a working definition of SPM). There is no way to specify a SPM in XML schema for validation with a standard XML validator; however, where possible the XML standard includes a machine readable SPM attribute.
The IEEE standard XML schema does not contain any extensibility placeholder. In other words, you cannot add your own data elements to it. However, you can easily integrate the standard XML schema into a larger schema, or even integrate portions (such as specific datatypes) from that schema into a larger schema. For example, a historical record of all the attempts on a SCO could be defined by an XML schema that specifies metadata about the record and the learner, and then a collection of records, each with its own metadata regarding attempt dates, LMS version used, etc. and each containing an XML fragment that conforms to the IEEE 1484.11.3 schema. In that case, you don't extend the standard schema internally, but rather you reuse the standard schema as component in an extended schema.
The IEEE data model is a superset of the SCORM 1.2 data model. In other words, all the data elements defined in the SCORM 1.2 data model can be mapped into the IEEE data model and thus into the IEEE XML binding. For some elements like cmi.core.lesson_status or interactions, this remapping may require some minor massaging or interpretation of the data.
This opens some very interesting opportunities. For example, it means that only one schema is required to store historical data of past attempts, regardless of whether this was for SCORM 1.2 or for SCORM 2004. It also means that the same data extraction or report generation scripts or XSL can be used to extract data or generate reports, regardless of which version of SCORM was used for the content delivery.
An XML schema to represent the state of an activity tree can be constructed using the IEEE 1484.11.3 schema as a building block within a larger schema. The IEEE 1484.11.3 can be used to represent the "CMI data model" part of the state of each leaf activity.
The schema file (.xsd) is freely downloadable from the IEEE web site, where it is placed in a fixed location that is referenced by the standard itself. The URL is shown in the References section below. However, making good use of the .xsd file really requires reading both the 1484.11.1 and 1484.11.3 standard documents, which must be purchased from the IEEE unless your organization already has a subscription to IEEE standards.
Institute of Electrical and Electronics Engineers, Inc. (2006). IEEE Std 1484.11.3 - 2005 IEEE Standard for Learning Technology - Extensible Markup Language (XML) Schema Binding for Data Model for Content Object Communication. E-ISBN: 0-7381-4879-2. ISBN: 0-7381-4878-4.
Institute of Electrical and Electronics
Engineers, Inc. (2005). ieee_1484.11.3-2005.xsd.
Retrieved July 1, 2006 from http://standards.ieee.org/downloads/1484/1484.11.3-2005/ieee_1484.11.3-2005.xsd
(Right click
here to download)
Institute of Electrical and Electronics Engineers, Inc. (2005). IEEE Std 1484.11.1 - 2004 IEEE Standard for Learning Technology - Data Model for Content to Learning Management System Communication. ISBN: 0-7381-4489-4
Institute of Electrical and Electronics
Engineers, Inc. (2006). Errata to IEEE Standard for
Learning Technology-Data Model Content Object
Communication. Retrieved July 1, 2006 from http://standards.ieee.org/reading/ieee/updates/errata/1484.11.1-2004.pdf
(Note: This errata document only specifies a title correction
for the standard to align it with 1484.11.3. All future
references should use the new title: IEEE Standard for Learning
Technology-Data Model for Content Object Communication.