There has been a recent uptick in the number of questions received by our support group involving cmi5 implementations, specifically related to creating cmi5 content or activities. While these questions are a great indicator that adoption of cmi5 is on the rise, they also gives us a chance to see what the most frequent hurdles are in implementing the specification and allows us to try to get documentation out in front of those adopters.
So what’s the most common question people ask when creating an assignable unit (AU)?
When working with the Rustici Software implementation of the LMS side of cmi5 (via Rustici Engine or SCORM Cloud), users that already understand web services and xAPI usually falter when attempting to send the “initialized” statement and they receive a message indicating “Forbidden cmi5 allowed statement: session not active.” The “initialized” statement is the first statement expected to be sent by the AU, and indicates to the LMS that the content has been successfully launched and is ready to capture experience data.
For people already somewhat familiar with xAPI, sending an “initialized” statement is pretty straightforward. They have the right verb, include the registration ID, and even generally manage to include the rest of the context template received from the LMS.LaunchData document. Then why is it such a hassle? What are they missing? Generally what solves their problem is including the cmi5 profile Activity in the context object, specifically in the category list. (If you aren’t familiar with the Context object, and its Activity lists I suggest you review the Context deep dive.)
Enter cmi5 defined
By including this Activity in the correct place in the context, “context.contextActivities.category”, the statement is signaling to the receiving LRS (and consequently LMS) that this statement is special. The LMS can recognize the statement as being a cmi5 “defined” statement; a statement that it must pay attention to for its own processing. The statements are said to be “cmi5 defined” because they are the statements codified in the cmi5 specification as being meaningful to the LMS. The “cmi5 defined” statement set is designed for capturing session details and core eLearning principles such as pass/fail, content completion, duration, and score. The cmi5 profile Activity to include is:
{
"objectType": "Activity",
"id": "https://w3id.org/xapi/cmi5/context/categories/cmi5"
}
All other statements sent by an AU and accepted by the LRS on behalf of the LMS are said to be “cmi5 allowed” statements. These statements include the context template mentioned earlier which includes the cmi5 session identifier, include the same registration, and otherwise are considered part of the cmi5 session. But they do not specifically affect the session, nor does the LMS necessarily understand them semantically. In other words, if a video is being played by a cmi5 AU, that AU may capture statements about the video experience as part of the session, but the LMS may not doing anything special with video statements.
Statements that do not include the context template with the session identifier are not considered to be “cmi5 allowed” nor “cmi5 defined”, and implementations may reject requests including these types of statements based on LRS permissions.
Back to our developer’s problem
After correcting the context and sending an “initialized” cmi5 defined statement, the LMS marks the session as initialized and subsequent statements can be recorded.
By leveraging the Context Activity list in this way, cmi5 is following intentional core principles of how to structure xAPI statement data to optimize LMS performance while providing a consistent information model around the concept of an AU launch session inherent in the majority of launchable experiences.
