CMI 5 Subgroup Meeting Notes – September 15th, 2023

cmi5 Subgroup Meeting Notes – September 15th, 2023

xAPI Version Compatibility in cmi5 The group continued its discussion about how to handle xAPI version compatibility/references in cmi5.

What are the differences between xAPI 1.0.x and 2.0?

xAPI 2.0 has 2.0 Timestamps requirement
- cmi5 requires timestamp in same format – but in UTC time
xAPI 2.0 has Context Agents and Context Groups (added – not in 1.0.x)
xAPI 2.0 statement signatures are different than 1.0.x
Different Version number in HTTP request headers
xAPI 2.0 features went from “Shoulds to Shalls”

Backward/Forward Compatibility:

1.0.x -> 2.0 - In general 1.0.x statements will work with 2.0, except for HTTP request headers.
2.0 -> 1.0.x - xAPI 1.0.x did not specifically allow for additional objects in a statement (or specifically prohibit it) – therefore theoretically 2.0 statements could work in 1.0.x if headers were ignored. (as xAPI 2.0 has more objects than 1.0.x)

Should cmi5 1.0 (Quartz) stay ambiguous? (1.0.x vs 2.0)

Yes, xAPI Profiles should be xAPI version agnostic
- 2.0 profiles may not match 1.0.x in the future (at present they do)

What about cmi5 conformance?

Catapult does not check xAPI versions.
xAPI 2.0 will not pass LRS testsuite with xAPI 1.0.x requests
Best Practices will have to address 1.0.x vs 2.0. In reality, the cmi5 LMS would have to address the issue with AU statement transformation
We can’t do anything with the old cmi5 spec to address this issue – we can address in cmi5 2.0 (and best practices)
The 1.0.3 LRS testsuite rejects Extra properties in Statements (like Context Agents and Context Groups)

Possible cmi5 2.0 spec changes to address xAPI version compatibility:

A cmi5 LMS should transform/normalize/convert AU statements for xAPI version compatibility with its LRS's xAPI version.
Course Structure – AU properties – add xAPI version to metadata

Provide feedback