The short answer

Existing item banks and LMS exports frequently use QTI 2.x. QTI 3 uses current web markup and updated package, accessibility, and results models. Keep the source package and validate the target package.

QFlowLearn imports QTI 1.2, QTI 2.1/2.2, and QTI 3.0. After import, authors review fidelity, warnings, metadata, accessibility fields, and scoring before the content becomes approved QTI 3 material.

Comparison by platform responsibility

Area QTI 2.x concern QTI 3 direction
Web delivery Implementations often carry older markup and product-specific rendering assumptions. QTI 3 uses interaction markup for current web components and browser delivery.
Accessibility Accessibility information may exist across item metadata and platform conventions. Accessibility and Personal Needs and Preferences have a clearer end-to-end role.
Packaging Real packages vary by exporter, version, manifest quality, and local extensions. The package contract is more uniform, but importers must still inspect every dependency.
Results Many platforms rely on proprietary result records around portable item content. The results model supports a stronger standards-aligned evidence path.
Migration Reviewers must identify the source behavior before conversion. Conversion should end in validated QTI 3 plus a reviewable transformation report.

Do not treat a version conversion as a file rename

A QTI package contains more than XML with a version marker. It can include manifests, assessment tests, item resources, response declarations, response processing, stylesheets, media, shared stimuli, metadata, and exporter-specific conventions. A successful conversion has to preserve meaning across those relationships.

Keep the original package and record its format and warnings. Convert it to one internal model. Export the target package after review. Do not replace an unsupported interaction without reviewer approval.

Questions to ask a QTI vendor

  1. Which QTI versions can you import, author, deliver, and export?
  2. Do you preserve original XML and package assets for review?
  3. How does the system report unsupported interactions and response processing?
  4. Can reviewers compare source behavior with the converted item?
  5. Which accessibility and PNP capabilities survive the full path?
  6. What validates the exported package before publication?
  7. Which capabilities does the system support now? Which capabilities are certification targets?

Use standards claims with precision

File support does not prove complete QTI conformance. Product support does not prove formal certification. Procurement language must name the supported package versions, interaction families, processing behavior, accessibility coverage, validation evidence, and certification status separately. QFlowLearn publishes that distinction in its QTI 3 capability matrix.

For the normative specification and certification program, consult the 1EdTech QTI resources.

Requirements review

Compare your requirements with QFlowLearn support

Send a source package, a requirements table, or a failure scenario. QFlowLearn will identify its support status and required review work.