CMI 5 Subgroup Meeting Notes – Oct 13th, 2023

cmi5 Subgroup Meeting Notes – Oct 13th, 2023

Rejection would be of the course or course structure format during the import process
“Could two different LMSs have different rejection criteria and still be cmi5 compliant?”
Manual Test in CATAPULT – give a package, this should be importable, given another package, this should be rejected
Scripts were required – code functions file has to include these to automate the testing.
“Could an LMS test the URLs and if finding a bad one, reject the package?” The best the LMS could probably do would indicate if “this” was a URL.
Provided a valid course structure format, the LMS MUST allow an import function to be successful.
It seems that section 6 requires import wrt section 13 compliance
"Because the cmi5 specification does not specify the implementation specifics
- around the concept of package import, retrieval of launch URLs, and whether
- an LMS implements an automated way to waive AUs or abandon sessions, each
- LMS must implement these functions based on their own implementation specifics."

New requirement?

The LMS MUST reject the import of the Course Structure if it is not as defined in Section 13.0 Course Structure Data Requirements.
- This may not be as useful as just listing out all of the rejection possibilities, as there are valid course structures that must be rejected (duplication, for example)
The LMS MAY reject the import of the Course Structure if it is not as defined in Section 14.0 Course Package.
- https://github.com/adlnet/CATAPULT/blob/main/requirements/requirements.json#L24 (Derived requirements have “d”)
- https://github.com/adlnet/CATAPULT/blob/main/lts/procedure.md#invalid-package-rejection-verification

** Note to go through the standard and update with all “implied requirements” from CATALPULT

We did this exercise earlier, but the recollection was that it was in the context of adding to the current version and to not make breaking changes
The course structure format needs to be appended to allow the specification of an LRS version (must support multiple).
- Needs a controlled vocabulary
The reconciliation of all the LRS data could be problematic if AUs end up sending to multiple LRSs (but this wouldn’t be required).
The same endpoint could be provided to all AUs (which is the current practice)
This would be allowable by the xAPI 2.0 (About header to negotiate): * 2.0.0: "An LRS shall not reject requests based to this resource on their version header as would otherwise be required by Versioning. * https://opensource.ieee.org/xapi/xapi-base-standard-documentation/-/blob/main/9274.1.1%20xAPI%20Base%20Standard%20for%20LRSs.md?ref_type=heads#get-request-3
We’ve always tried to put the onus on the LMS for implementation
Most LMSs that wouldn’t know what to do with this will just dump it to an LRS that will know.
This requirement is not required “The LMS must send an Abandoned statement if the AU launches and fails due to an incompatible version of xAPI.”
1. It would be rejected at import time
2. "Fails” is not specific criteria
3. Use of abandoned and other current version requirements will catch this use case

Provide feedback