For the purposes of course development, you will need to learn how to work with three components: the SCORM API, the CMI data model, and the course manifest (imsmanifest.xml).
Here’s a quick overview of each component. I will provide real-world examples later in this series.
The SCORM API
The SCORM API is a JavaScript object made available through the browser’s window object. The API allows the course to issue commands to the LMS, such as getting/setting data and exiting a course. The LMS is responsible for providing the API and exposing it via window to the course.
There are eight methods (functions) provided by the SCORM 1.2 API:
- LMSInitialize(“”)
- Starts the SCORM session.
- Returns a boolean in string format, indicating success of call.
- Quirk: Always requires a single parameter, set to an empty string.
- LMSFinish(“”)
- Ends the SCORM session.
- Returns a boolean in string format, indicating success of call.
- Quirk: Always requires a single parameter, set to an empty string.
- LMSGetValue(cmi_field)
- Retrieves and returns the value of the specified CMI field.
- Value provided in string format.
- LMSSetValue(cmi_field, value)
- Sets the value of the specified CMI field.
- All values must be submitted as a string, including numbers and objects (e.g. “23” instead of 23).
- Returns a boolean in string format, indicating success of call.
- LMSCommit(“”)
- Instructs the LMS to persist (save) the course data to the database.
- Returns a boolean in string format, indicating success of call.
- Quirk: Always requires a single parameter, set to an empty string.
- LMSGetLastError()
- Retrieves and returns the error code generated by the previous SCORM API call.
- Error code is a number provided in string format.
- LMSGetErrorString(error_code)
- Retrieves and returns a brief message describing the error specified by error_code.
- Message provided in string format.
- LMSGetDiagnostic(error_code)
- Retrieves and returns a more detailed message about the error specified by error_code.
- Message provided in string format.
SCORM 2004 renamed the API methods, but the API functionality is identical:
- Initialize()
- Terminate()
- GetValue()
- SetValue()
- Commit()
- GetLastError()
- GetErrorString()
- GetDiagnostic()
The CMI Data Model
SCORM is a reference model (hence the RM in SCORM), which means it repurposes existing standards. The CMI (computer managed instruction) data model was part of the AICC specification, which preceded SCORM.
The CMI data model can be thought of as a list of fields available in a database, including items like learner’s name and the most recent course bookmark.
The meat of the SCORM system lies in the CMI data model, which provides course developers with access to specific bits of data, including the student’s name via cmi.core.student_name, the score via cmi.core.score.raw, the course bookmark via cmi.core.lesson_location field, etc.
SCORM’s CMI fields, especially with SCORM 2004, are actually pretty diverse and support many useful tasks: track course objectives, track user interactions (including answers provided by the learner, and how much time they spent in the interaction), gather comments from the learner as they progress through the course, and enable the learner to specify preferences about language, audio playback, and more.
You can explore the full list of available CMI fields on Rustici Software’s handy SCORM Run-Time Reference Guide.
The Course Manifest
A SCORM course requires a manifest XML file, which contains key metadata such as course name, course ID, and version number. It also contains nodes informing the LMS where to find your course files.
The manifest is always named imsmanifest.xml and is always located at the root of the SCORM package.
The file is named imsmanifest because it utilizes the IMS Global Learning Consortium’s content packaging standards. (Note the IMS Global Learning Consortium has rebranded to 1EdTech Consortium.)
I’ve previously written about manifests, and examples can be found on GitHub. I will provide a functional example later in this series.