CMI 5 Subgroup Meeting Notes – Mar 22nd, 2024 - AICC/CMI-5_Spec_Current GitHub Wiki
cmi5 Subgroup Meeting Notes – Mar 22nd, 2024
- Bill McDonald
- Andy Johnson
- Christopher Thompson
- Brian Miller
- Florian Tolk
- George Vilches
- Jim Taite
- Megan Bohland
- Yifei Dong
Course Structure Extensions
The group continued its discussion course structure extensions.
- Do we want to protect our “element space” ?
- If you have a prefix – you can use extension elements for external XSD - Small risk of collisions of elements
- Process from movement (promotion) of extension to specification.
Option #1 - Enhance the existing approach by clarifying the requirements for namspaces….
- Possible issues with external XSD's - Problematic XML parsers?
- "Root vs Relative” element question for referencing external XSD’s….
- Confirmed: external XSD can NOT require a root element
- Open question once the parser sees the external namespace tag it ignores it?
- The spec should be clarified as follows:
13.1.5 Vendor Specific Metadata (Extensions) Course Designers MAY place their own namespaced elements into the course structure and thus define an extension for the source structure specification. For that they MUST provide a XML Schema Definition and SHOULD provide a human readable specification describing these vendor specific extensions. These extensions MUST keep the course structure XML valid. Any elements not defined in the specification must have non-empty namespace referring to the XML schema definitions with the extensions. An importing LMS MAY ignore these elements. Therefore the extension SHOULD be created in such a manner that a course is still useable if the LMS does not support the additional elements. To achieve a larger distribution of their extension course designers SHOULD choose a free or open source license for their specification and make it publicly available.
Option #2 – Create an extensions element to be placed within selected spec elements.
- A new element - Would placed be in most elements (e.g. BLOCK, AU, Course,) -
- The current approach is problematic as a lot of developers don’t use the XSD.
- Barriers to entry? (like parsers that don’t use XSDs)
IEEE Gitlab Status
IEEE Gitlab for cmi5 is still not deployed yet. In addition to the license agreements (outstanding CLA's), there are policy discussions regarding the separation of actual Standard from Supplementary Content that still need to be resolved.
Best Practices
The group continued it review of the best practice for “satisfied” statements for AU’s and proposed a draft as follows:
Best Practice #13 – LMS should always send “satisfied” statements for AU’s. It is recommended that the LMS sends a cmi5 “allowed” statement (with a satisfied verb) when an AU has met its moveOn criteria. The statement must also include the same AU activityId used in cmi5 defined statements.