SCORM Driver

Web developers don’t have time to learn all the complexities of SCORM, so our SCORM Driver is all about making any learning content compliant.

SCORM Driver

  • Automatically adjusts to each learning standard
  • Excellent compatibility… it works everywhere
  • You can convert content yourself, or have us do it for you


SCORM Driver is free for
non-commercial use.

cmi5 with SCORM Driver

In general, very little code will need to change for clients that have implemented against the Driver API, as is the intention of Driver itself. The primary differences revolve around the configuration and packaging, and are consistent with previous versions of Driver and the other learning standards it supports.

It is important to understand the concepts of the Course Structure and Assignable Units (AU) in cmi5 for the packaging aspect. Driver implements the AU runtime portion of cmi5. Having said that, the packaging concept of a Course Structure in cmi5 means that multiple AUs can be combined in various ways into a single Course Structure package. Driver scripts themselves could be shared across AUs in a Course Structure package, but ultimately Driver only concerns itself with a single AU at a time.


A “package” in cmi5 generally consists of a zip file that contains a Course Structure metadata file (similar to a manifest) that must be called `cmi5.xml`. That file contains metadata for a top level structure, the Course Structure, that must include an identifier, a title, and a description. Within this “course” there is at least one AU metadata structure that also includes an identifier, title, and description. Title and description in both cases may be included in multiple languages, via language code identifiers which must be included. Identifiers must be different between the Course Structure and AU, and will ultimately be captured via xAPI statements and so should follow best practices for xAPI Activity identifiers. An AU id must be unique within a Course Structure file.

AUs may be assigned additional metadata for the following properties: launchMethod, masteryScore, moveOn, activityType, url, launchParameters, entitlementKey. Some properties are not supported by Driver because they do not have analogs in the other learning standards, and all of them are available via non-public APIs, but shouldn’t be used for software trying to support multiple standards.

AU Properties that should be used by Driver based software:

  • id – required
  • title – required
  • description – required
  • launchMethod – required, “OwnWindow” or “AnyWindow” – Determines where the AU is opened
  • url – The launch point of the content, with Driver based packages this is generally the `scormdriver/indexAPI.html` file.
  • masteryScore – Decimal value between 0 and 1 inclusive with 4 places of precision that determines what score must be achieved on the AU to be considered “passed”.
  • moveOn – Used at the Course Structure (or Block) level to determine whether or not an AU has been satisfied sufficiently to go to another part of the block or course.
  • activityType – IRI that corresponds to an xAPI Activity Type and may be used by an LMS to indicate to the user what type of Activity the AU is (see
  • launchParameters – available via the `GetLaunchData` Driver function

Driver distributions include an example single AU template file called `cmi5.xml` that should be edited for the above properties. The other files normally included with all Driver based content should still be included but should not need to be edited.


Finish Functions

cmi5 doesn’t support closing the content with different statuses, such as suspend, so calling any of the Finish functions (TimeOut, Suspend, Finish, Unload, etc.) should be virtually identical.

Pass/Fail/Complete and Scoring

cmi5 restricts the use of pass and complete to a single call per registration (not per launch), Driver attempts to keep track of when these values have already been permanently recorded and will trigger errors on multiple calls to them. Multiple calls to them (even switching between pass/fail) within a single launch session will work up to the point at which they are committed (but will not be recorded in the xAPI statement stream).

Scores are tracked via the pass/fail statements in cmi5. When a “masteryScore” is provided to the AU by the LMS (most often because it was included in the Course Structure AU metadata), then Driver will automatically call either `SetPassed` or `SetFailed` when `SetScore` has been called. If a “masteryScore” is NOT provided to the AU and `SetScore` is called then a call to one of `SetPassed` or `SetFailed` must be called by the user for permanent capture of the score.

Statement Handling

All statements are queued locally in Driver objects until the `CommitData` function is called, which is called automatically by all of the normal Finish functions, at which time they are POSTed to the LRS.

Interactions and Other non-cmi5 Statements

cmi5 does not specify anything around recording assessments or interaction data. Driver functions related to interaction recording will still work and are implemented using “cmi5 allowed” statements that are similar to those from the Tin Can implementation.

Similar to the Tin Can implementation, a statement is written whenever a bookmark is set.


The following elements of the Driver API are not implemented for cmi5: objective functions, timeout related functions, LMS comments, navigation requests, progress measure.


The configuration of Driver is essentially unchanged. It is now possible to specify “CMI5” as the value for the `strLMSStandard` which forces Driver to execute assuming it is using the cmi5 standard, but this should be avoidable and simply allow Driver’s auto learning standard detection to work. Auto detection works in cmi5 by looking at the launch query string parameters (as specified in cmi5) and checking for “endpoint” and other parameters to allow it to differentiate between cmi5 and Tin Can launches.

The `tc-config.js` introduced with the Tin Can implementation is not necessary for cmi5.


Official cmi5 support landed in Driver major version 7 and is the primary feature of that release. Our Driver implementation is currently complete, and licensed Driver customers can request an upgrade through support.

Our LMS supporting (Engine) implementation of cmi5 is complete. We expect to use the Engine implementation in our hosted SaaS offering (Cloud) product for a beta testing period to allow Driver customers and other cmi5 package implementers to test. We expect this implementation to be available during Q4 of 2016.