liminfoSCORM/xAPI Reference
Free reference guide: SCORM/xAPI Reference
About SCORM/xAPI Reference
The SCORM/xAPI Reference is a comprehensive cheat sheet for e-learning interoperability standards used in Learning Management System (LMS) development and instructional design. It covers SCORM 1.2 and SCORM 2004 side by side, including content package structure (ZIP with imsmanifest.xml), the distinction between SCO (Shareable Content Object) and Asset, API discovery for finding window.API (1.2) or window.API_1484_11 (2004), session lifecycle with Initialize/Terminate, data read/write with GetValue/SetValue, Commit for persistence, and error handling with GetLastError codes.
The CMI data model section documents both SCORM 1.2 (cmi.core.* with lesson_status, score.raw 0-100, session_time in HHHH:MM:SS.SS format) and SCORM 2004 (cmi.* with separated completion_status and success_status, score.scaled -1 to 1, session_time in ISO 8601 PT format). It covers suspend_data for storing custom JSON state (4096 chars in 1.2, 64000 in 2004), interactions for recording quiz responses across 8-10 interaction types, and objectives for multi-objective tracking in 2004. SCORM 2004 advanced topics include sequencing with controlMode and deliveryControls, pre-condition and exit-condition rules, navigation requests (continue, previous, choice, exit), and rollup rules for aggregating child activity status.
Beyond SCORM, the reference covers xAPI (Experience API / Tin Can) with Actor-Verb-Object statement structure, Result objects with score/success/completion/duration, the ADL standard verb registry, Learning Record Store (LRS) REST API for statement submission and querying, and Context objects for recording instructor, team, and activity hierarchy. LTI 1.3 entries document the OIDC-based launch flow with JWT claims, Names and Roles Provisioning (NRPS), and Assignment and Grade Services (AGS) for score synchronization. QTI 3.0 entries cover assessment item XML structure with response declarations and 13 interaction types from choice to file upload.
Key Features
- SCORM 1.2 vs 2004 comparison table with API names, status values, score ranges, and sequencing capabilities
- Complete content package structure with imsmanifest.xml schema, organizations, resources, and SCO/Asset types
- API lifecycle: discovery (window traversal), Initialize, GetValue/SetValue, Commit, Terminate, and error codes
- Full CMI data model for both versions: lesson status, scores, time formats, suspend_data, interactions, and objectives
- SCORM 2004 sequencing: controlMode, pre/post condition rules, navigation requests, and rollup aggregation
- xAPI statement structure with Actor-Verb-Object, Result, Context, and 22 ADL standard verbs
- LTI 1.3 integration: OIDC launch flow, JWT claims, NRPS, AGS score posting, and Deep Linking
- QTI 3.0 assessment items with response declarations, correct responses, and 13 interaction types
Frequently Asked Questions
What is the difference between SCORM 1.2 and SCORM 2004?
SCORM 1.2 uses a simpler API (window.API) with 6 lesson status values, scores from 0-100, and no sequencing. SCORM 2004 uses API_1484_11, separates completion from success status, supports scaled scores from -1 to 1, adds complex sequencing and navigation with branching rules, supports multiple objectives, and increases suspend_data from 4096 to 64000 characters.
What is a SCO and how does it differ from an Asset?
A SCO (Shareable Content Object) communicates with the LMS via the SCORM API, calling Initialize/Terminate and tracking learning status. An Asset is simple content (images, PDFs) that does not communicate with the LMS. In imsmanifest.xml, SCOs have adlcp:scormtype="sco" while Assets have adlcp:scormtype="asset". Each SCO should represent one learning objective, and data cannot be shared between SCOs.
How does a SCO find the LMS API object?
The SCO traverses the window hierarchy by checking window.API (SCORM 1.2) or window.API_1484_11 (SCORM 2004) starting from the current window, moving up through parent frames with window.parent. If not found in the parent chain, it checks window.opener for popup windows. This discovery process must succeed before any API calls can be made.
What is suspend_data and how should I use it?
suspend_data is a free-form string field for storing custom learning state. In SCORM 1.2 it holds up to 4096 characters; in 2004, up to 64000. The recommended pattern is to serialize your state as JSON with JSON.stringify, store it with SetValue, and restore it with GetValue and JSON.parse on resume. This preserves quiz answers, current page, bookmarks, and any other progress data.
What is xAPI and how does it improve on SCORM?
xAPI (Experience API, also called Tin Can) tracks learning experiences as Actor-Verb-Object statements sent to a Learning Record Store (LRS). Unlike SCORM, xAPI works outside browsers (mobile apps, simulations, real-world activities), supports offline tracking, allows data sharing between systems, and is not limited to LMS-launched content. The 22 ADL standard verbs cover actions from "attempted" through "completed" to "voided".
How does LTI 1.3 work for tool integration?
LTI 1.3 uses OIDC (OpenID Connect) for authentication. The LMS (Platform) initiates a login request to the Tool, which responds with an authentication request. The LMS returns a signed JWT containing user identity, roles, and context. Core services include NRPS for user provisioning, AGS for grade synchronization (posting scores with activityProgress and gradingProgress), and Deep Linking for content selection.
What is QTI and what interaction types does it support?
QTI (Question and Test Interoperability) is an IMS standard for exchanging assessment items between systems. QTI 3.0 supports 13 interaction types: choice (multiple choice), order, associate, match, gapMatch (drag-and-drop fill), inlineChoice (dropdown), textEntry (short answer), extendedText (essay), hottext (text selection), hotspot (image region), slider, drawing, and upload.
How do SCORM 2004 sequencing rules work?
Sequencing is defined in imsmanifest.xml via controlMode (choice, flow, forwardOnly), pre-condition rules (e.g., skip if objective satisfied), exit-condition rules (e.g., exit after attempt), and rollup rules (aggregate child status to parent). Navigation requests like "continue", "previous", and "choice" are set via adl.nav.request and execute when Terminate is called.