If you are buying or commissioning training content, three acronyms come up quickly: LMS, SCORM and xAPI. They are often mentioned as if they were alternatives to one another. They are not. They sit at different points in the same chain, and mixing them up is how a team ends up with a course that marks everyone complete but cannot show how anyone actually did.
This guide explains what each one is, what it can and cannot record, where a newer specification called cmi5 fits, and how to decide what your course needs. It is written for people who commission training, not for the developers who implement it.
The Short Answer
- An LMS (learning management system) is the software that hosts courses, assigns them and keeps the record of who finished what.
- SCORM is a set of conventions for packaging course content and letting it report simple results, such as completion and a score, to an LMS from inside a web browser.
- xAPI is a data format and web service for recording learning experiences in much more detail, to a separate store called a learning record store (LRS).
As a rule of thumb, SCORM fits a course that runs in a browser and needs a completion, a pass or fail and a score. xAPI is for when you need the detail behind that score, or when the learning does not happen inside a browser-based course.
What an LMS Does
A learning management system hosts courses, assigns them to people and records who completed them. For regulated training that record is often the point, because the LMS is where a manager or an auditor goes to look. We cover that side in our glossary entry on compliance tracking.
The LMS is also the system the older standard is written around. SCORM describes how content and an LMS talk to each other. xAPI describes how any activity, including a course in an LMS, talks to a record store. Which one fits depends on what you want that record to contain.
What SCORM Is
SCORM stands for Sharable Content Object Reference Model. The SCORM guide on scorm.com is careful about the word: it says SCORM is not actually a standard, but a set of conventions that combines existing standards and explains how to use them together. It has three parts.
- Content packaging. A manifest file named imsmanifest tells the LMS what is in a course and which file launches first, so the course can be imported without a person configuring it by hand.
- Run-time communication. While the content plays, it talks to the LMS through a JavaScript API that the LMS provides.
- Sequencing and navigation. Rules for how a learner moves between content items. This part exists in SCORM 2004 only.
What SCORM Can Record
The run-time data model is a defined set of fields. It includes completion status, success status (passed or failed), a score, session time, a bookmark so a learner can resume, and fields for interactions and objectives. A course can tell the LMS that a learner scored 95% on a test. The content works within the fields the model gives it.
The Browser Constraint
This is the limit that matters whenever content is anything other than a standard web course. According to the run-time guide on scorm.com, the JavaScript API is the only way content can communicate with the LMS. Content cannot use web services, form posts or database writes. It has to be delivered over the web and run in a window that can reach the LMS's API through its parent or opener chain.
A course that runs in that kind of window fits the arrangement well. A mobile app, or a tool that is not delivered as a web page inside the LMS, does not fit it naturally. Whether a particular vendor offers a bridge is a question for that vendor.
Which Version
Two versions come up. SCORM 1.2, which scorm.com describes as the most widely adopted, and SCORM 2004, which adds sequencing and navigation. That page is undated, so read the adoption claim as historical. Ask your LMS vendor which versions it supports before content is built.
What xAPI Is
xAPI, the Experience API, was formerly called the Tin Can API and is an effort of the ADL Initiative. It was published in October 2023 as IEEE 9274.1.1-2023, which the IEEE lists as an active standard. The IEEE describes it as a JSON data model format and a RESTful web service for communication between activities and a Learning Record Store.
Statements
The core unit is the statement. The specification requires every statement to have an actor (who), a verb (the action) and an object (the activity), and a statement can also carry a result and a context. Statements are written in JSON.
Each verb is identified by an IRI, so that a system reading a statement can infer its meaning and one identifier cannot stand for two meanings. Extensions let a statement carry custom data, and the specification says an LRS must not reject a statement because of what its extensions contain.
In plain terms, a statement says: this learner did this to this thing, with this outcome. A pass or fail is one statement. So is a learner's answer to a single quiz question, if the content is built to send it.
The Learning Record Store
Statements go to an LRS, a server whose job, in the specification's words, is receiving, storing and providing access to learning records. It is separate software from the LMS, although some LMSs include one. That makes "where does the LRS live?" one of the first questions to settle.
Because xAPI is a web service rather than a browser API, whatever reports does not have to be a web page. A web course, a mobile app or a desktop tool can send statements the same way. That is our reading of the IEEE scope text, which speaks of activities communicating with an LRS and says nothing about browsers.
Where cmi5 Fits
xAPI on its own does not say how an LMS imports a course, launches it, or tells the content who the learner is. cmi5 fills that gap. Its specification describes interoperable run-time communication between an LMS and content units called Assignable Units, using xAPI. Under cmi5 the LMS must implement an LRS and launch the unit. The first edition, Quartz, is dated June 1, 2016.
If cmi5 matters to your project, ask your LMS vendor whether and how it supports it.
SCORM and xAPI Side by Side
| Question | SCORM | xAPI |
|---|---|---|
| How content reports | Calls a JavaScript API the LMS provides | Sends JSON statements to a web service |
| Where the data goes | The LMS | A learning record store (LRS) |
| Where content runs | In a browser window that can reach the LMS | Any activity that can send requests to the LRS |
| What it records | A defined set of fields | Statements, plus context and custom extensions |
| Packaging and launch | Defined, using a manifest file | Not covered, which is what cmi5 adds |
| What it is | Conventions that combine existing standards | IEEE 9274.1.1-2023 |
Which One Do You Need
Start with the question our glossary raises: do you want to know whether people completed the training, or how well they performed? They are different questions and they need different data. Our entries on xAPI and SCORM and the digital performance record go into the same distinction.
- A browser-based course with a completion and a pass or fail result. SCORM is enough, provided your LMS supports the version you build for.
- A course where the detail behind the score matters. For example, which questions learners got wrong, or learning that happens outside the LMS. SCORM can give you a score and some interaction data. xAPI is built to record richer detail, such as each answer. Check that your LMS or an LRS can receive it before assuming it will.
- A course the LMS must launch and track that also reports detail. This is the case cmi5 was written for.
Settle this before the content is built. Reporting is a design decision: someone has to choose which events are worth sending, and the content has to be built to send them.
Four questions for an LMS vendor will save most of the confusion:
- Which SCORM versions do you support?
- Do you include an LRS, or connect to one?
- Do you support cmi5?
- Can we export our learners' records if we change systems?
Frequently Asked Questions
They do different jobs. SCORM is a convention for packaging and launching browser content and reporting a fixed set of results to an LMS. xAPI is a data format and web service for recording experiences in an LRS. cmi5 exists to combine launch from an LMS with xAPI reporting.
For a course that runs in a browser and needs completion, a pass or fail and a score, yes, provided your LMS supports the SCORM version the course is built for. If you also want to see how learners answered, or to record learning that happens outside the course, look at xAPI.
If you use xAPI, yes, because statements need somewhere to be stored. Some LMSs include one and some do not. cmi5 requires the LMS to implement one.
The one your LMS supports. SCORM 1.2 and SCORM 2004 are both in use, and 2004 adds sequencing and navigation. Confirm with your vendor first, because it is cheaper than rebuilding content later.
Completion tells you a learner reached the end. Performance tells you how well they did, and on what. SCORM handles completion and a score well. Detail about what a learner did along the way needs xAPI and content built to report it.
Sources
- SCORM Explainedscorm.com
- SCORM Run-Time Communicationscorm.com
- Experience API: About the Experience APIADL Initiative
- Experience API: DataADL Initiative
- xAPI-Spec repository READMEADL Initiative
- IEEE 9274.1.1-2023: JSON Data Model Format and RESTful Web Service for Learner Experience Data Tracking and AccessIEEE
- cmi5 Specification, Quartz First EditionAICC and ADL Initiative
Need interactive lessons for your LMS?
We create interactive lessons for clients. Tell us which LMS you use and what you need to track, and we will build the lessons to report it.
