You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Question and Test Interoperability specification (QTI) is an IMS standard that broadly overlaps our Capa-based ProblemBlock, as well as some Open Response Assessment (ORA) essay types. It most commonly shows up when talking about the Common Cartridge spec (CC is the container format, while QTI specifies much of the content itself). Version 3.0 of QTI brings better support for HTML5 and vastly improved accessibility features, and it is slated for public release in March of 2022.
QTI does not have a standard reference implementation. Different LMS vendors support different versions of the specification to different degrees. Open edX support for QTI is limited, and mostly consists of using the cc2olx script as an import tool to convert QTI XML to OLX in a rough way that works for some common problem types. While this approach is sufficient for the current pilot phase, it will be extremely difficult to get to full feature support using this method.
We can develop full support for the QTI spec and support its assessment types as peers to XBlocks (instead of doing conversion to XBlocks). Some benefits that this would bring:
Open edX would support a much larger pool of content and read-write interoperability with other learning systems.
QTI 3.0 has much richer accessibility features than Capa.
QTI is far better specified than Open edX’s Capa/ORA/OLX.
Possible Approach: Cross-platform implementation in Rust with Python + WebAssembly bindings
The open source ed-tech community as a whole would benefit from having an open source, cross-platform reference implementation of QTI. Instead of making a Python library like we normally would, it's worth considering a Rust-based implementation that could have Python and WebAssembly bindings. Adding a language to the stack requires careful consideration, but there are some compelling upsides:
WASM portability would mean it could be adopted by essentially any LMS.
WASM portability would allow for rich front-end editing/preview functionality.
WASM security would allow us to create sandboxed extensions to QTI that add some of the more powerful dynamic features of Capa in a safer way.
Rust’s algebraic data types are a good fit for QTI’s large data model.
The Question and Test Interoperability specification (QTI) is an IMS standard that broadly overlaps our Capa-based ProblemBlock, as well as some Open Response Assessment (ORA) essay types. It most commonly shows up when talking about the Common Cartridge spec (CC is the container format, while QTI specifies much of the content itself). Version 3.0 of QTI brings better support for HTML5 and vastly improved accessibility features, and it is slated for public release in March of 2022.
QTI does not have a standard reference implementation. Different LMS vendors support different versions of the specification to different degrees. Open edX support for QTI is limited, and mostly consists of using the cc2olx script as an import tool to convert QTI XML to OLX in a rough way that works for some common problem types. While this approach is sufficient for the current pilot phase, it will be extremely difficult to get to full feature support using this method.
We can develop full support for the QTI spec and support its assessment types as peers to XBlocks (instead of doing conversion to XBlocks). Some benefits that this would bring:
Possible Approach: Cross-platform implementation in Rust with Python + WebAssembly bindings
The open source ed-tech community as a whole would benefit from having an open source, cross-platform reference implementation of QTI. Instead of making a Python library like we normally would, it's worth considering a Rust-based implementation that could have Python and WebAssembly bindings. Adding a language to the stack requires careful consideration, but there are some compelling upsides:
I have a really minimal proof of concept project for this.
The text was updated successfully, but these errors were encountered: