Skip to content

CMI 5 Subgroup Meeting Notes – Oct 13th, 2023

Bill McDonald edited this page Oct 20, 2023 · 1 revision

cmi5 Subgroup Meeting Notes – Oct 13th, 2023

Attendee List

  • Andy Johnson
  • Florian Tolk
  • Brian Miller
  • Henry Ryng
  • Jim Taite
  • Megan Bohland
  • Simon Hsu
  • Thomas Turrell-Croft

Notes


Requirement 1 on https://github.com/AICC/CMI-5_Spec_Current/wiki/CMI-5-Subgroup-Meeting-Notes-%E2%80%93-September-29th%2C-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."

https://github.com/adlnet/CATAPULT/blob/main/lts/lib/lms.template.js

New requirement?

** 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

All Previous cmi5 Meeting Minutes/Notes

https://github.com/AICC/CMI-5_Spec_Current/wiki

cmi5 on GitHub:

http://aicc.github.io/CMI-5_Spec_Current/

Clone this wiki locally