SCORM and xAPI both exist to get a record of what a learner did into a system that can report on it. They disagree about almost everything else: where the content runs, who it talks to, what it is allowed to say, and how it gets there in the first place. If you are choosing between them for a new course, or trying to work out why an LMS accepts one package and shrugs at another, the differences that matter are architectural rather than cosmetic.

SCORM: a JavaScript API inside the LMS window

A SCORM course is a set of web pages that the LMS launches in a browser window or frame it controls. When the course starts, its JavaScript walks up the window hierarchy (through parent and opener) looking for an object the LMS has placed there. In SCORM 1.2 that object is called API; in SCORM 2004 it is API_1484_11. Everything the course reports goes through that object, and nothing else.

A SCORM 1.2 session looks like this from the course’s side:

API.LMSInitialize("");
var status = API.LMSGetValue("cmi.core.lesson_status");
API.LMSSetValue("cmi.core.score.raw", "85");
API.LMSSetValue("cmi.core.lesson_status", "passed");
API.LMSCommit("");
API.LMSFinish("");

SCORM 2004 renames the calls to Initialize, GetValue, SetValue, Commit and Terminate, and splits the single lesson status into cmi.completion_status and cmi.success_status, but the shape is the same (how 1.2 and 2004 differ in detail). The course can only read and write the elements of a fixed data model the specification defines. It cannot invent a field, and it cannot talk to anything but the LMS that launched it.

The packaging is just as fixed. A SCORM package is a zip with imsmanifest.xml at its root, and the manifest tells the LMS which file to launch:

<manifest identifier="fire-safety" version="1.0"
          xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2"
          xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2">
  <organizations default="org1">
    <organization identifier="org1">
      <title>Fire safety basics</title>
      <item identifier="item1" identifierref="res1">
        <title>Fire safety basics</title>
      </item>
    </organization>
  </organizations>
  <resources>
    <resource identifier="res1" type="webcontent"
              adlcp:scormtype="sco" href="index.html">
      <file href="index.html"/>
    </resource>
  </resources>
</manifest>

That rigidity is SCORM’s strength. Any conformant LMS can import the zip, launch it, and know exactly what cmi.core.lesson_status means. It is also the limit: the learning has to happen in a browser, inside an LMS session, while a window that holds the API is still open.

xAPI: statements sent to a Learning Record Store

xAPI, the Experience API, came out of an ADL research effort known as Project Tin Can, which is why you will still see it called Tin Can. It drops the in-browser API entirely. Instead, whatever is doing the tracking sends statements over HTTP to a Learning Record Store (LRS), a web service whose job is to accept, store and return them.

A statement is a JSON object built around an actor, a verb and an object, with optional result and context:

{
  "actor": {
    "name": "Dana Ruiz",
    "mbox": "mailto:dana.ruiz@example.com"
  },
  "verb": {
    "id": "http://adlnet.gov/expapi/verbs/completed",
    "display": { "en-US": "completed" }
  },
  "object": {
    "id": "http://example.com/courses/fire-safety",
    "definition": { "name": { "en-US": "Fire safety basics" } }
  },
  "result": {
    "score": { "scaled": 0.85 },
    "success": true,
    "completion": true
  }
}

Verbs and activities are identified by IRIs, so anyone can define new ones. A statement can say that someone completed a course, but it can just as well say that someone attempted a simulation, watched a video to a certain point, or attended a workshop. The sender does not have to be a web page in an LMS frame. A mobile app, a desktop simulator or a server-side process can post statements, and a client that loses its connection can queue them and send them later.

The LRS can be built into an LMS or run on its own, and more than one system can read from it. Alongside statements, the specification defines places to keep other data: a state resource that plays roughly the role of SCORM’s suspend_data, and profile resources for data about an activity or an agent.

What xAPI gives up is the agreed meaning. In SCORM every LMS knows what passed is. In xAPI, a report on “completed” only works if every source used the same verb IRI the same way, and that agreement has to be designed by whoever builds the courses and the reports.

What plain xAPI does not define

The xAPI specification describes statements, the LRS and how to talk to it. It does not say how content is packaged, how an LMS imports it, or how the content learns which LRS to send to and with what credentials. There is no xAPI equivalent of imsmanifest.xml in the specification itself.

The gap was filled by convention. Rustici Software, which ran the Tin Can research for ADL, published launch guidelines that most LMSs with xAPI support follow. The package is a zip with a tincan.xml file at its root, listing the activity and its launch file:

<?xml version="1.0" encoding="utf-8"?>
<tincan xmlns="http://projecttincan.com/tincan.xsd">
  <activities>
    <activity id="http://example.com/courses/fire-safety"
              type="http://adlnet.gov/expapi/activities/course">
      <name lang="en-US">Fire safety basics</name>
      <description lang="en-US">Evacuation routes and extinguisher use.</description>
      <launch lang="en-US">index.html</launch>
    </activity>
  </activities>
</tincan>

When the LMS launches it, it appends query parameters to the launch URL: endpoint (the LRS address), auth (the credentials), actor, registration and activity_id. The course reads them and starts sending statements.

This works, but notice what it leaves open. Each LMS decides for itself what counts as complete, because nothing obliges a course to send a particular verb. The credentials travel in the URL to code running in the learner’s browser. And because it is a convention rather than part of the specification, support for tincan.xml varies from one LMS to the next. An authoring tool’s “xAPI” export is usually this package, so it is worth asking an LMS vendor specifically whether they import tincan.xml packages, not only whether they “support xAPI”.

cmi5 closes the gap

cmi5 is an ADL specification that sits on top of xAPI and supplies what plain xAPI leaves out. It defines a course structure file, cmi5.xml, a launch procedure in which the LMS hands the content a one-time URL to fetch its credentials rather than putting them in the launch link, a small vocabulary of defined statements (launched, initialized, completed, passed, failed, terminated and a few others) with rules for which side sends each, and rules the LMS applies to decide when a learner has finished. It is the closest thing to “SCORM, but on xAPI”, and it deserves its own article rather than a paragraph here.

The differences side by side

  • Where tracking goes. SCORM writes to the LMS that launched the course, through a JavaScript object in the browser. xAPI posts JSON over HTTP to an LRS, which may or may not be part of an LMS.
  • What can be tracked. SCORM is limited to its fixed data model. xAPI statements can describe any activity using any verb.
  • Where learning can happen. SCORM needs a browser window launched by the LMS. xAPI accepts statements from anything that can make an HTTP request, including apps and offline clients that send later.
  • Packaging and launch. SCORM defines both, through imsmanifest.xml. Plain xAPI defines neither; tincan.xml is a widely followed convention, and cmi5 is the specification that standardises it.
  • Sequencing. SCORM 2004 lets a manifest define navigation rules between SCOs. xAPI has nothing comparable.
  • Agreed meaning. SCORM’s status values mean the same thing in every LMS. xAPI’s verbs mean what the people using them agree they mean.
  • LMS support. SCORM import, 1.2 above all, is a baseline LMS feature. xAPI support, and tincan.xml import in particular, needs checking per platform.

When each fits

Choose SCORM when the course is a self-contained piece of web content that lives in an LMS and the reporting you need is completion, pass or fail, score and time. That describes most compliance, onboarding and policy training. SCORM 1.2 in particular is the safe default when you do not control which LMS the course will end up in, which is the usual position for a freelancer or an agency delivering to clients.

Choose xAPI when the learning happens somewhere an LMS window cannot follow: a mobile app, a simulator, a performance support tool, an in-person session someone records afterwards. It also fits when you need detail that SCORM’s data model has no field for, such as each answer and attempt in a branching scenario, and when someone will actually build reports on that detail. An LRS full of statements nobody queries is just a more complicated way of recording completion.

Choose cmi5 when you want xAPI’s data but also need an LMS to launch the course, decide completion consistently and keep credentials out of the URL.

Many courses can ship in more than one format. Authoring tools commonly export the same project as SCORM 1.2, SCORM 2004 or xAPI, so the decision can be made per client rather than once for the course.

If you have been handed a zip and are not sure which standard it targets, the SCORM package tester will tell you: it recognises SCORM 1.1, 1.2 and 2004 packages as well as tincan.xml and cmi5.xml packages, and plays and logs the API calls of the SCORM ones. It does not run xAPI or cmi5 content, so for those it can confirm what you have, not how it behaves.