Skip to contents

The files generated by the rqti package are fully compatible with the OPAL LMS. Furthermore, adhering to QTI 2.1 specifications, these files are suitable for use in any LMS supporting QTI 2.1. You can find a list of QTI-compatible LMS platforms here: https://en.wikipedia.org/wiki/QTI.

To upload your tasks to an LMS, create a zip archive containing the test and import it into the target LMS.

We have conducted compatibility tests by uploading rqti zip archives to LMS platforms such as OpenOlat and Canvas. In most instances, tasks generated by rqti behaved as expected within these LMS platforms. However, we have identified some inconsistencies, documented below. Since our files are QTI 2.1 compatible (with verification and automated tests for all task types), issues typically arise from the LMS side.

If you use a different LMS and encounter problems, please open an issue on GitHub: https://github.com/shevandrin/rqti/issues

OPAL

As noted above, our files are fully compatible with OPAL, and we even support selected QTI 2.2 features.

In particular, downloadable files and calculator support are available in OPAL, but only in connection with QTI 2.2.

Extra assessmentTest Attributes

Concretely, this functionality is currently based on custom attributes in the assessmentTest element:

<assessmentTest
  ...
  data-downloads="file://downloads/;"
  data-features="scientific-calculator;mark-items;show-test-time;">

Under QTI 2.2, this is permissible, although it should be clearly documented.

A simpler alternative would be to include such files directly in the content package, for example through a dedicated downloads folder referenced in the manifest. However, this raises an important issue in exam settings, where file downloads may be restricted, for example by Safe Exam Browser. In such cases, files should be managed explicitly as downloadable LMS resources rather than being encoded in the test definition itself. This would be possible without relying on custom data- attributes.

More generally, we believe such attributes should be avoided whenever possible, because they weaken the idea of a common standard.

With regard to the calculator, this may be better understood as a feature of the LMS rather than of the test itself. Accordingly, it could be configured at the LMS or test-delivery level rather than within the QTI test definition. The same consideration applies to other data-features such as mark-items and show-test-time. More broadly, the additional flexibility introduced in QTI 2.2 is not necessarily problematic; it may also indicate where the standard itself still lacks useful features.

Tolerance for Text Gaps

Tolerance handling for text-entry questions is currently implemented via extra tags, that are not compatible with QTI. In this case, however, we do see a legitimate need for extending the QTI standard, because tolerance is an important feature for text-response processing and is not adequately supported by the base specification.

Example:

<setOutcomeValue identifier="SCORE_codieren">
  <mapTolResponse xmlns="http://bps-system.de/xsd/imsqti_ext_maptolresponse"
                  identifier="codieren"
                  tolerance="2"
                  toleranceMode="absolute"/>
</setOutcomeValue>

Allow Pasting in Essay Questions

The attribute data-allowPaste in extendedTextInteraction is fine in QTI 2.2. However, this functionality can usually be handled at the system level, for example through Safe Exam Browser, and therefore does not need to be encoded in the QTI test definition itself.

MathML

A custom namespace prefix for MathML is ignored. For example, the following does not work:

Referencing files

You cannot reference files or images (e.g. via <a href=...>). They must be embedded directly in the file via base64 encoding.

xmlns:m="http://www.w3.org/1998/Math/MathML"
...
<m:math>
  ...
</m:math>

By contrast, using the MathML namespace directly on the math element works:

<math xmlns="http://www.w3.org/1998/Math/MathML">
  ...
</math>

OpenOlat

The following functionalities are currently non-functional on OpenOlat:

  • The parameters include_lower_bound and include_upper_bound in the tolerance customization of numeric gaps are ignored. This is a minor problem since it is usually irrelevant whether the bounds are included or not. Still, we are actively investigating this issue.

Canvas

Note that Canvas exports to the fairly old QTI 1.2 version, which makes it difficult to understand what is happening internally and to diagnose or resolve these issues.

The following functionalities encounter problems when used with Canvas:

  • The inlineChoice task type does not appear to be supported.
  • Feedback information seems to be ignored during import.
  • textEntryInteraction elements are incorrectly imported as essay questions, rendering both numeric and text gap items non-functional.
  • Handling of text input length and placeholders is not supported.
  • Tables are converted to either match or categorization interactions, which leads to several issues:
    • One-in-row tables lose distractors (i.e., options that are not mapped to any row); one-in-column tables have not yet been tested. Directed pairs work correctly (since there are no distractors); MPC tables have not yet been tested.

Test files

Official conformance test files for QTI v2.1:

https://www.imsglobal.org/developers/apipalliance/conformance/QTIconformanceresources.cfm

These resources are incomplete. In particular, they do not include textEntryInteraction items with a responseDeclaration of baseType="float" (i.e., numeric gap questions), and only a single variant of matchInteraction is provided. Several other interaction types are also missing.

Additional examples can be obtained from the implementation guide:

https://www.imsglobal.org/question/qtiv2p1/imsqti_implv2p1.html

APIs

OPAL provides a strong API that supports direct upload of QTI files.

OpenOlat also offers an API, but it is currently unclear whether QTI files can be uploaded directly. The API documentation can be accessed at http://localhost:8080/restapi/api-docs/ for a local installation, although a server URL can of course be used as well. Potentially relevant endpoints include /repo/entries (PUT) and /qpool/items (POST, PUT). However, we have not yet tested these endpoints.

Blackboard provides an API as well: https://developer.blackboard.com/portal/displayApi. At present, it is unclear whether this API supports QTI upload, and we have not yet tested it. Based on the available documentation, this currently seems unlikely.

Canvas provides an API that appears to support both uploading and migrating QTI files, although we have not yet tested this functionality: https://mitt.uib.no/doc/api/all_resources.html, see endpoint /api/v1/accounts/:account_id/content_migrations