cmi5 will play a key role in moving toward a more modern learning ecosystem by ensuring plug and play interoperability between conformant systems. This cmi5 technical overview will help systems professionals understand the key concepts of the specification in order to build conformant systems.

Import and Validation of Course Packages

An LMS must be able to import a cmi5 course package in at least these three formats: standalone XML file, 32-bit ZIP format and 64-bit ZIP format. In addition, an LMS may have the capability to support other formats.

Data types used in the course structure data model:

  • Decimal. XSD definition: “xs:decimal”
  • IRI. XSD definition: “xs:anyURI”
  • String. XSD definition: “xs:string“
  • Langstring. XSD definition: <xs:element name=”langstring” maxOccurs=”unbounded” minOccurs=”1″/>
  • objectiveReference. XSD definition: <xs:element name=”objectives” type=”referencesObjectivesType” minOccurs=”0″/>

Learn more about course structures and formats in Section 14.0 of the cmi5 specification.

Back to top

Registration Creation

A registration is an enrollment of a learner in a learning activity, and the registration ID uniquely reflects this. As the learner advances, the registration ID stays with the learner until learning activity completion and review of completion. The LMS creates a new registration for new enrollment instances, which could be for recurrent courses or retaking courses. The LMS places the registration value in the query string with the value being based on the learner’s enrollment. 

The registration property value is generated by the LMS, and the LMS uses the launch URL to pass it to the Assignable Unit (AU).

Back to top

Handling moveOn Criteria

The LMS uses the the moveOn criteria to determine if an AU is satisfied for the purposes of determining overall course satisfaction or if prerequisites were met. 

The AU is satisfied when the LMS receives: 

  • A statement with the “Passed” verb.
  • A statement with the “Completed” verb.
  • Statements with the “Completed” and “Passed” verbs.
  • A statement with either of the “Completed” or “Passed” verbs.

moveOn must be provided in the LMS Launch Data for the AU plus registration. The LMS must add moveOn to the “Launched” statement.  

Not specifying the moveOn criteria (or specifying it as NotApplicable) will have one of the following results:

  • Before the learner even launches an AU, the course is marked satisfied upon registration.
  • If at least one AU has a moveOn criteria specified (other than NotApplicable), then the course would be Satisfied upon completion of those AUs.

The best practice is including moveOn criteria for each AU in a course structure.

Back to top

Launch URL Generation

The AU is be launched by the LMS with a URL having query string launch parameters. The launch parameters must be name/value pairs in a query string that is included in the AU launch URL.

If the AU’s URL requires a query string for other purposes, then the names can’t conflict with the parameters in the specification, and the AU must be able to process the query string launch parameters in any order. Each value for the associated names is URL-encoded. See more about content launch mechanisms.

Back to top

Session Creation and Tracking

A session is a period of time that is marked by the launch of an AU and continues until termination or abandonment. The session must have a session ID, which is a unique identifier (string) for a single AU launch session based on actor and course registration. The LMS generates the value for the session ID and records the session ID in the State API prior to launching an AU.

Back to top

Session and Statement Validation

In the LMS.LaunchData Activity State, the LMS needs to have a contextTemplate object that includes the value for session ID placed in an “extensions” property. 

JSON example:

{
    "extensions":
      "https://w3id.org/xapi/cmi5/context/extensions/sessionid": "e5c1de64-90c8-4549-a08f-074696876809"
}

 The LMS provides the session ID as an extension for all statements it makes in the LRS directly.

Back to top

fetch URL

The AU uses the fetch URL to acquire an authorization token, which is used by the AU being launched, and the LMS is responsible for placing the fetch URL in the launch URL.

The fetch URL is a “one-time use” URL and should generate one of the following errors if there are multiple attempts:

  • Already in Use or Expired. 
  • General Security Error. 
  • General Application Error. 

Learn more about the authorization token fetch URL.

The fetch URL returns a JSON structure using a Content-Type of “application/json”. 

Example JSON structure:

{
    "auth-token": "QWxhZGRpbjpvcGVuIHNlc2FtZQ=="
}
Back to top

Handling returnURL

In a web-browser activity where the LMS requires the AU to redirect upon a learner’s exit, then the LMS uses the returnURL when launching the AU. If the learner should be redirected, then the LMS may include the returnURL.

Back to top

Questions? Ask us anything.

If you still have cmi5 systems questions, our team is here to help.