| # IMS Question and Test Interoperability Migration Guide ## Version 2.1 Public Draft (revision 2) Specification

Copyright © 2006 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS GLC.
Document Name: IMS Question and Test Interoperability Migration Guide

Date Issued: | 8 June 2006
Caution: this specification is incomplete in its current state. The IMS QTI project group is in the process of evolving this specification based on input from market participants. Suppliers of products and services are encouraged to participate by contacting Mark McKell at mmckell@imsglobal.org. This specification will be superseded by an updated release based on the input of the project group participants. Please note that supplier's claims as to implementation of QTI v2.1 and conformance to it HAVE NOT BEEN VALIDATED by IMS GLC. While such suppliers are likely well-intentioned, IMS GLC member organizations have not yet put in place the testing process to validate these claims. IMS GLC currently grants a conformance mark to the Common Cartridge profile of QTI v1.2.1. The authoritative source of products and services that meet this conformance is contained in the IMS online product directory http://www.imsglobal.org/ProductDirectory/directory.cfm Thank you for your interest in and support of IMS QTI. IPR and Distribution Notices Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation. IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf. Copyright © 2006 IMS Global Learning Consortium. All Rights Reserved. If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm. This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group. Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html. The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns. THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

## Table of Contents

1. Introduction
2. References
3. Mapping Response/Render Types to Interactions
  3.1. Migrating render_fib
  3.2. Migrating render_hotspot
4. Specifying Coordinates
5. ASI Reference
  5.1. <and>
  5.2. <assessfeedback>
    5.2.1. Attributes: view, ident, title
  5.3. <assessment>
  5.4. <assessmentcontrol>
    5.4.1. Attributes: hintswitch, solutionswitch, view, feedbackswitch
  5.5. <assessproc_extension>
  5.6. <conditionvar>
  5.7. <decvar>
    5.7.1. Attribute: varname
    5.7.2. Attribute: vartype
    5.7.3. Attribute: defaultval
    5.7.4. Attribute: minvalue, maxvalue
    5.7.5. Attribute: cutvalue
    5.7.6. Attribute: members
  5.8. <displayfeedback>
    5.8.1. Attribute: feedbacktype
    5.8.2. Attribute: linkrefid
  5.9. <duration>
  5.10. <flow>
    5.10.1. Attribute: class
  5.11. <flow_label>
  5.12. <flow_mat>
  5.13. <interpretvar>
    5.13.1. Attribute: view
  5.14. <item>
    5.14.1. Attribute: maxattempts
    5.14.2. item.ident
    5.14.3. Attribute: title
    5.14.4. Attributes: label, xml:lang
  5.15. <itemcontrol>
  5.16. <itemfeedback>
    5.16.1. Attribute: view
    5.16.2. Attribute: ident
    5.16.3. Attribute: title
  5.17. <mataudio>
  5.18. <matbreak>
  5.19. <material>
    5.19.1. Attributes: label, xml:lang
  5.20. <matimage>
    5.20.1. Attribute: imagtype
    5.20.2. Attributes: label, height, width
    5.20.3. Attributes: uri
    5.20.4. Attribute: embedded
    5.20.5. Attributes: x0, y0
    5.20.6. Attribute: entityref
  5.21. <mattext>
    5.21.1. Attribute: texttype
    5.21.2. Attributes: label, xml:lang
    5.21.3. Attribute: xml:space
    5.21.4. Attribute: charset
    5.21.5. Attributes: x0, y0, width, height
    5.21.6. Attributes: uri, entityref
  5.22. <not>
  5.23. <objectbank>
  5.24. <objectives>
    5.24.1. <view>
  5.25. <or>
  5.26. <other>
  5.27. <outcomes>
  5.28. <outcomes_metadata>
  5.29. <outcomes_processing>
  5.30. <presentation>
    5.30.1. Attributes: x0, y0, width, height
    5.30.2. Attributes: label, xml:lang
  5.31. <presentation_material>
  5.32. <qticomment>
  5.33. <qtimetadata>
  5.34. <questestinterop>
  5.35. <reference>
  5.36. <render_choice>
    5.36.1. Attribute: shuffle
    5.36.2. Attribute: minnumber
    5.36.3. Attribute: maxnumber
  5.37. <render_fib>
    5.37.1. Attributes: encoding, charset
    5.37.2. Attribute: fibtype
    5.37.3. Attributes: rows, columns, maxchars
    5.37.4. Attribute: prompt
    5.37.5. Attribute: minnumber, maxnumber
  5.38. <render_hotspot>
    5.38.1. Attribute: minnumber
    5.38.2. Attribute: maxnumber
    5.38.3. Attribute: showdraw
  5.39. <render_slider>
    5.39.1. Attribute: orientation
    5.39.2. Attributes: lowerbound, upperbound
    5.39.3. Attribute: startval
    5.39.4. Attributes: step, steplabel
    5.39.5. Attribute: minnumber, maxnumber
  5.40. <respcondition>
    5.40.1. Attribute: continue
    5.40.2. Attribute: title
  5.41. <response_group>
    5.41.1. Attributes: ident, cardinality, rtiming
  5.42. <response_label>
    5.42.1. Attribute: rshuffle
    5.42.2. Attribute: rarea
    5.42.3. Attribute: rrange
    5.42.4. Attribute: labelrefid
    5.42.5. Attribute: ident
    5.42.6. Attribute: match_group, match_max
  5.43. <response_lid>
    5.43.1. Attribute: rcardinality
    5.43.2. Attribute: rtiming
    5.43.3. Attribute: identifier
  5.44. <response_num>
    5.44.1. Attribute: numtype
    5.44.2. Attributes: ident, cardinality, rtiming
  5.45. <response_str>
    5.45.1. Attributes: ident, cardinality, rtiming
  5.46. <response_str>
    5.46.1. Attributes: ident, cardinality, rtiming
  5.47. <resprocessing>
    5.47.1. Attribute: scoremodel
  5.48. <rubric>
    5.48.1. Attribute: view
  5.49. <section>
  5.50. <sectioncontrol>
  5.51. <sectionfeedback>
  5.52. <sectionpostcondition>
  5.53. <sectionprecondition>
  5.54. <sectionproc_extension>
  5.55. <selection_metadata>
  5.56. <selection_ordering>
  5.57. <setvar>
    5.57.1. Attribute: varname
    5.57.2. setvar.action
  5.58. <solution>
    5.58.1. <Attribute: feedbackstyle
  5.59. <solution_material>
  5.60. <varequal>
    5.60.1. Attribute: case
    5.60.2. Attribute: respident
    5.60.3. Attribute: index
  5.61. <vargt> and <vargte>
    5.61.1. Attributes: respident, index
  5.62. <varinside>
    5.62.1. Attribute: areatype
    5.62.2. Attributes: respident, index
  5.63. <varlt> and <varlte>
    5.63.1. Attributes: respident, index
  5.64. <varsubset>
    5.64.1. Attribute: setmatch
6. QTI Metadata Reference
  6.1. <qmd_computerscored>
  6.2. <qmd_feedbackpermitted>
  6.3. <qmd_hintspermitted>
  6.4. <qmd_itemtype>
  6.5. <qmd_levelofdifficulty>
  6.6. <qmd_material>
  6.7. <qmd_maximumscore>
  6.8. <qmd_renderingtype>
  6.9. <qmd_responsetype>
  6.10. <qmd_scoringpermitted>
  6.11. <qmd_status>
  6.12. <qmd_timedependence>
  6.13. <qmd_timelimit>
  6.14. <qmd_toolvendor>
  6.15. <qmd_topic>
  6.16. <qmd_typeofsolution>
  6.17. <qmd_weighting>
7. Results Reporting Reference
  7.1. <asi_description>
  7.2. <asi_metadata>
  7.3. <assessment_result>
    7.3.1. Attributes: asi_title, ident_ref
  7.4. <context>
  7.5. <control>
    7.5.1. Attributes: solution_switch, view, hint_switch, feedback_switch
  7.6. <correct_response>
  7.7. <date>
  7.8. <extension_context>
  7.9. <extension_grade>
  7.10. <extension_result>
  7.11. <extension_score>
  7.12. <feedback_displayed>
    7.12.1. Attributes: asi_title, ident_ref, entityref, uri
  7.13. <generic_identifier>
  7.14. <grade_cut>
  7.15. <item_result>
    7.15.1. Attributes: asi_title, ident_ref, entityref, presented
  7.16. <name>
  7.17. <num_attempts>
  7.18. <num_items>
  7.19. <num_items_attempted>
  7.20. <num_items_presented>
  7.21. <num_sections>
  7.22. <num_sections_presented>
  7.23. <objective>
  7.24. <qti_comment>
  7.25. <qti_result_report>
  7.26. <response>
  7.27. <result>
  7.28. <duration>
  7.29. <score_average>
  7.30. <score_cut>
  7.31. <score_interpretation>
  7.32. <score_max>
  7.33. <score_min>
  7.34. <score_normalized>
  7.35. <score_reliability>
  7.36. <score_std_error>
  7.37. <section_result>
  7.38. <summary_result>

## 1. Introduction

This document provides advice and guidelines on converting data conforming to the version 1 ASI data model into version 2. For readers who are already familiar with version 1 it can also be used as a quick introduction to the new concepts in version 2.

## 2. References

CSS
  Cascading Style Sheets, level 2
  http://www.w3.org/TR/CSS21/
IMS_CP
  IMS Content Packaging Specification, Version 1.1.3

## 3. Mapping Response/Render Types to Interactions

In QTI version 1, the interactions between the candidate and the delivery engine were described using a two-stage model. Firstly, the type of data required from the candidate was defined using one of the response_lid, response_xy, response_str, response_num or response_grp elements. The style or rendering of the item was then determined by choosing one of the render_choice, render_hotspot, render_slider or render_fib elements.

In version 2, this model has been updated to specify more types of interaction. The data type is still defined separately (using a responseDeclaration) but this appears outside the presentation (now called the itemBody) so that it can be used more easily by systems that don't parse the item's content. The render types have been replaced by an expanded set of more tightly defined interactions that clearly state which data types they can and can't support. To help migration of version 1 content, the following table can be used to find the version 2 interaction that corresponds to each version 1 response/render combination.

response_/render_ | choice | hotspot | slider | fib
--- | --- | --- | --- | ---
lid | For single or multiple cardinality use choiceInteraction, for ordered cardinality use orderInteraction. | For single or multiple cardinality use hotspotInteraction, for ordered cardinality use graphicOrderInteraction. See Migrating render_hotspot below for more information. | For single cardinality use choiceInteraction, slider behaviour must be communicated through an accompanying stylesheet and is now outside the scope of this specification. Multiple and ordered cardinality are undefined. | Undefined
xy | Undefined | For single or multiple cardinality use selectPointInteraction, ordered cardinality is no longer supported. See Migrating render_hotspot below for more information. | Undefined | Undefined
str | Undefined | Undefined | Undefined | Use extendedTextInteraction or textEntryInteraction. See Migrating render_fib below for more information.
num | Undefined | Undefined | For single cardinality use sliderInteraction. Multiple and ordered cardinality are undefined. | Use extendedTextInteraction or textEntryInteraction. See Migrating render_fib below for more information.
grp | For single or multiple cardinality use associateInteraction, for multiple cardinality: undefined. | Undefined | Undefined | Undefined

### 3.1. Migrating render_fib

In version 1, render_fib was used to describe all types of free text entry interaction. In version 2, this type of interaction is separated into two types: extendedTextInteraction and textEntryInteraction. The difference between them is the role that the interaction takes in the content model. A textEntryInteraction behaves like a simple run (span) of text and can be used for requesting the candidate to type a response that will appear in the context of the surrounding text, for example, completing missing words from a given sentence. In contrast, an extendedTextInteraction behaves more like a whole paragraph of text (with an optional prompt) and would typically be used for obtaining longer responses ranging from 'short' answers to complete essays.

When migrating content from version 1, choosing between these two representations requires the application of some heuristics as the intention was not specified. A reasonable rule is to assume that render_fib elements that contain a mixture of material and response_label(s) should be translated into a series of separate textEntryInteractions, one for each response_label. In version 2, this mapping requires a new response variable to be declared for each textEntryInteraction. Otherwise, an extendedTextInteraction can be implied.

### 3.2. Migrating render_hotspot

In version 1, render_hotspot was used to describe interaction types that made use of areas defined relative to the coordinate system of a screen area containing an image. This coordinate-based relationship between the interaction and the material meant that hotspot questions could be created that interacted with several images simultaneously. Indeed, the diagram given in the version 1 information model encouraged this use. In addition, the location of the material objects that defined the images within the content-model was not constrained.

This definition of the coordinate system for hotspot interactions was impractical unless coordinates were also given for all of the material in the item (see Specifying Coordinates below for a related discussion). As a result, interoperability of hotspot questions was hampered and clarification requested.

In version 2, this issue has been resolved with a more restrictive model for the graphical interactions. As a result, when migrating content from version 1 only hotspot questions that made use of a single image can be converted directly. Items which located the material object containing the associated matimage as a child element of render_hotspot should be easier to migrate. Similarly, items that ignored coordinate positioning of material and used image-relative coordinates to describe hotspot areas instead of notional screen coordinates can be mapped to the new information model directly.

## 4. Specifying Coordinates

Version 1 of QTI defined the attributes x0, y0, width and height for specifying the exact position of images or other material relative to the screen. Version 2 inherits its material model from XHTML and therefore does not have concepts that correspond to x0 and y0 and specifying the dimensions of objects in the content model is limited to img and object.

Removing detailed information about the presentation (layout/styling) of the content from the QTI information model was a key requirement in version 2 to help support the exchange of items that can work on as wide a variety of systems as possible thereby improving accessibility. Specifying detailed information about layout is also a more general problem than the one QTI is trying is to solve and so it makes sense to look for a more general solution in a similar way to QTI's adoption of elements from XHTML to solve the problem of describing the structure of the material.

The general solution to providing presentation-orientated information for documents marked up in XML is to provide a stylesheet and this approach is encouraged in QTI through the stylesheet class. This specification does not mandate the use of one stylesheet language over another, however, because [CSS] is fairly well established as a language for controlling the presentation of HTML documents it is used in this document to illustrate how style can be applied to QTI items.

When migrating content from QTI version 1 that specifies coordinates it is recommended that the corresponding element in version 2 is given an id and that this id is used to associate fixed positioning rules in the associated stylesheet. For example, the element from a version 1 item below:

    <material>
     <matimage imagtype="image/jpeg" x0="300" y0="500" width="200" height="200" uri="image.jpg"/>
     <altmaterial>
     <mattext>A Pretty Picture</mattext>
     </altmaterial>
    </material>

can be represented in version 2 as:

    <img id="image01" src="image.jpg" width="200" height="200" alt="A Pretty Picture"/>

The following CSS rule can then be used to represent the missing coordinates:

    #image01 { position: fixed; top: 500px; left: 300px }

Version 1 items that specify coordinates only for some of the material objects are harder to migrate because the relationship of the objects with fixed positions to those without is not described in the specification—custom rules will need to be applied based on additional knowledge of the original target delivery engine.

## 5. ASI Reference

### 5.1. <and>

No change

### 5.2. <assessfeedback>

Replaced by testFeedback in version 2.

#### 5.2.1. Attributes: view, ident, title

In version 2, the ident attribute is replaced by the identifier attribute. The title attribute is unchanged. The view attribute is replaced by the showHide attribute.

### 5.3. <assessment>

Replaced by assessmentTest which is the top level element; an assessmentTest will always contain at least one testPart and assessmentSection.

### 5.4. <assessmentcontrol>

No longer available in version 2.

#### 5.4.1. Attributes: hintswitch, solutionswitch, view, feedbackswitch

In version 2, there is no alternative available for hint_switch, solution_switch is replaced by showSolution, view is no longer needed, feedback_switch has been replaced by showFeedback.

### 5.5. <assessproc_extension>

No longer available in version 2.

### 5.6. <conditionvar>

In version 2 this element is no longer needed. Expressions are direct descendants of the responseIf or responseElseIf objects. If a conditionvar contained multiple test operators then it was an implicit and, in version 2, it must be explicitly replaced by an and.

### 5.7. <decvar>

In version 2, decvar has been replaced by outcomeDeclaration which appears in the information model as a direct descendant of assessmentItem and not as part of responseProcessing.

#### 5.7.1. Attribute: varname

Outcome variable names are identifiers in version 2 and share a namespace with response variables and the identifiers given to choices (version 1 response_labels). See Attribute: identifier below for more information.

#### 5.7.2. Attribute: vartype

Variables in version 2 are declared with a baseType. The version 1 types integer, string and boolean are the same. The two numeric types Decimal and Scientific both become simply float and the Enumerated type becomes identifier. An additional value, set, was referred to in the information model but was never defined.

#### 5.7.3. Attribute: defaultval

This is now represented by defaultValue, an optional part of each variableDeclaration.

#### 5.7.4. Attribute: minvalue, maxvalue

In early versions of the specification when (if at all) these constraints were applied to outcome variables caused some confusion. In version 2, it is not possible to specify constraints on variables when they are declared. In order to implement the version 1 behavior it is necessary to add additional responseConditions that check the value and set it appropriately at the end of the responseProcessing section.

The most common use for this type of bounds checking is to score multiple-response items where each individual response value has been assigned a score and these scores are summed to create a total. This allows incorrect responses to have a negative effect and correct ones to have a positive effect. This type of response processing is now enabled using a more direct method: the declaration of a mapping. The mapping forms part of the outcomeDeclaration and does have these constraints, through the two attributes lowerBound and upperBound.

#### 5.7.5. Attribute: cutvalue

No longer supported in version 2. If an assessmentItem has a cutvalue it is recommended that a second outcome variable is declared as a boolean, for example "MASTERY", and set during response processing explicitly.

#### 5.7.6. Attribute: members

This attribute supplied a set of identifiers to accompany declarations with vartype="Enumerated". In version 2, this vartype becomes identifier and it is not possible to restrict the outcome values in this way.

### 5.8. <displayfeedback>

In version 2, all feedback is controlled by the built-in outcome variable feedback. This variable is of multiple cardinality and is initially empty. The equivalent operation in version 2 is therefore to add an identifier which controls the desired feedback to this outcome variable. This is done using the multiple operator to combine the current value of the feedback outcome variable with the desired identifier.

#### 5.8.1. Attribute: feedbacktype

This attribute was poorly understood in version 1 and is no longer supported.

#### 5.8.2. Attribute: linkrefid

In version 1, this attribute was used to identify the feedback to be displayed. In version 2, this identifier should be added to the built-in feedback outcome variable as described above.

### 5.9. <duration>

In version 1 it was an attribute of the item. In version 2 it has been replaced by the timeLimits element in the assessmentTest.

### 5.10. <flow>

The flow element has been replaced along with the entire material model. In version 1, the flow element allowed the contents of the presentation to be grouped into sub-parts and structured hierarchically. In version 2, the contents of the itemBody are grouped by the familiar structural markup of HTML. In HTML, hierarchical structure is not strongly represented. Although multiple levels of headings are defined it is not easy to determine at which level within the document each paragraph is supposed to be. To solve this problem, the HTML div element is usually used. div is supported directly in QTI in the same way, however, when converting version 1 to version 2 some flow elements will correspond to div and some to other structural elements, such as p.

#### 5.10.1. Attribute: class

The class attribute on flow was designed to support stylesheet rules. In version 2, all the components of the itemBody can take a class attribute for the same purpose.

### 5.11. <flow_label>

The flow_label element is a constrained form of flow that is used within the render family of objects. Not well supported, its meaning was often not clear, though it was used to arrange the choices in a simple multi-choice question. The new interactions do not allow this sort of control over the choices and so there is no support for it in version 2.

### 5.12. <flow_mat>

The flow_mat element is a constrained form of flow that is used in contexts where only non-interactive material is allowed. See <flow> for more details.

### 5.13. <interpretvar>

Replaced by the interpretation attribute on outcomeDeclaration. In version 1, any material could be used whereas in version 2 it is limited to plain text.

#### 5.13.1. Attribute: view

Interpretations can no longer be restricted by view in version 2.

### 5.14. <item>

In version 2 the item element has been renamed assessmentItem to avoid confusion with the similarly named item element in IMS Content Packaging [IMS_CP].

#### 5.14.1. Attribute: maxattempts

No longer supported as a property of an item in version 2. Control over the maximum number of attempts allowed at an item is controlled when the item is used. See itemSessionControl.

#### 5.14.2.

The Integration Guide sets out a mechanism for packaging assessment items using the IMS Content Packaging specification [IMS_CP]. There are now potentially three places where items can be identified.

1. The identifier attribute of the assessmentItem itself, corresponds to the old ident attribute.
2. The identifier, as specified in the associated meta-data for the item. In fact, multiple identifiers are supported by the meta-data but one of them must have an entry that corresponds to the value of the assessmentItem's identifier attribute.
3. The identifier of the associated resource in a content package. This could be the same as the assessmentItem's identifier; however, resource identifiers are subject to different restrictions so some translation may be necessary.

#### 5.14.3. Attribute: title

In version 2, the length limit of 256 characters for item titles has been lifted.

#### 5.14.4. Attributes: label, xml:lang

No change.

### 5.15. <itemcontrol>

Outside the scope of assessmentItem in version 2.

### 5.16. <itemfeedback>

This element has been replaced with modalFeedback.

#### 5.16.1. Attribute: view

In version 2, modalFeedback cannot be made view dependent.

#### 5.16.2. Attribute: ident

In version 1, each piece of feedback was given an identifier and the displayfeedback element was used to control whether or not the feedback was to be shown. In version 2, this mechanism has changed. Feedback is now controlled by a built-in outcome variable feedback which is a container of identifiers set in the same way as other outcome variables (using setOutcomeValue). The visibility of a particular piece of (modal) feedback is then controlled by an identifier and an associated showHide attribute which determines if the feedback is normally hidden and shown when its identifier is in the feedback outcome variable (the default) or vice-versa.

Although the effect is roughly the same, the new mechanism is more powerful as it allows integrated feedback to be controlled in the same way and it also enables several pieces of feedback to be activated by the same identifier.

#### 5.16.3. Attribute: title

No change.

### 5.17. <mataudio>

Replaced by object.

### 5.18. <matbreak>

Replaced by br.

### 5.19. <material>

In version 1, the material element provided a general purpose wrapper for runs of text, images and other multimedia objects. In version 2, this wrapping is largely unnecessary as these objects are now placed into the information model directly.

#### 5.19.1. Attributes: label, xml:lang

If attributes of material have been used to assign properties to a specific group of material objects then these objects can be grouped in either a span or div as appropriate.

The material element could appear in many contexts in the version 1 model that are now more heavily constrained. The above mentioned mapping works for material contained directly in a presentation or flow but in other contexts use of div and/or span may not be allowed and no mapping will be possible, for example, when labeled material is used within <interpretvar>.

### 5.20. <matimage>

Replaced by img or object. This duplication of function is inherited from XHTML. When converting images used as part of interactions the object form is required.

#### 5.20.1. Attribute: imagtype

Note that img, though the more usual element in HTML, does not have a corresponding type attribute so the object form might be preferred if this information is needed.

#### 5.20.2. Attributes: label, height, width

Supported on both img and object.

#### 5.20.3. Attributes: uri

Equivalent to the src attribute of img or the data attribute of object.

#### 5.20.4. Attribute: embedded

In version 1, image data could be embedded directly into the QTI XML file using the embedded attribute to indicate the encoding used. This is no longer supported.

#### 5.20.5. Attributes: x0, y0

No longer supported directly in QTI, see Specifying Coordinates for details.

#### 5.20.6. Attribute: entityref

No longer supported in version 2.

### 5.21. <mattext>

Simple runs of text are now represented more directly and so there is no longer a need for the mattext element, the notional class textRun, which is simply bound to PCDATA in XML, will usually takes its place.

#### 5.21.1. Attribute: texttype

mattext was also used to include text marked up in other languages, such as HTML or RTF. Material marked up in HTML should translate without difficulty into version 2 as most of the familiar HTML elements are represented directly in the information model. Some elements that define aspects of style and layout, such as the HTML font element are not supported though—this information must now be placed in an associated stylesheet.

#### 5.21.2. Attributes: label, xml:lang

If attributes of mattext have been used to assign properties to a specific run of text (or complex content) then either span or div will have to be used instead, as appropriate. See also the note under Attributes: label, xml:lang on material.

#### 5.21.3. Attribute: xml:space

The xml:space attribute is no longer used, if space-preserved text is to be included in items then the pre element is required.

#### 5.21.4. Attribute: charset

No longer supported in version 2.

#### 5.21.5. Attributes: x0, y0, width, height

No longer supported directly in QTI, see Specifying Coordinates for details.

#### 5.21.6. Attributes: uri, entityref

Version 1 used mattext to incorporate externally defined material through a URI or external entity declaration and corresponding reference. The new content model, being based on XHTML, does not have a mechanism that corresponds to this. It was never completely clear what role this type of material was supposed to play. In version 2 it should either be included directly (marked up using the version 2 tags) or treated as an object.

### 5.22. <not>

No change.

### 5.23. <objectbank>

In version 2, objectbanks are created using IMS CP; sectionPart elements can only exist as part of an assessmentTest.

### 5.24. <objectives>

In version 2, item objectives are treated as part of the item's meta-data. In version 1, any material could be used whereas in version 2 they are limited to plain text. Also, in version 1, it was not clear whether objectives should have been displayed to the candidate when the item was presented or if they were just informational. As meta-data they are now only informational.

Since it is meta-data it is no longer stored in the assessmentItem of assessmentTest itself.

#### 5.24.1. <view>

Objectives with a restricted view are not supported in version 2, if the restriction is important then it is recommended that a rubricBlock is used instead. In fact, use of this attribute is suggestive of objectives that should be displayed along with the item's presentation.

### 5.25. <or>

No change.

### 5.26. <other>

The other operator was used in version 1 to match conditions that were "otherwise undefined". In practice, what this meant was that it was used as if it were a test that always returned true in the last respcondition in a response processing section. This adhered to the spirit of the definition when each respcondition had the default value for the continue attribute ("No") as the last respcondition would effectively catch situations in which all the previous tests had failed or had been "otherwise" untested for.

In version 2, responseCondition (the replacement for respcondition) now uses an if/else model which does not require the use of always-true test operators. Literal conversion from version 1 can use baseValue with a baseType of boolean and the value "true" in place of other if required.

### 5.27. <outcomes>

The outcomes element served an organizational function in version 1, grouping together the outcome declarations at the start of the response processing section. In version 2, outcomes are declared using outcomeDeclarations and appear as direct descendants of the assessmentItem eliminating the need for an equivalent definition.

### 5.28. <outcomes_metadata>

In version 1, outcomes_metadata was used to select subsets of the items in a section for aggregation based on their metadata. In version 2, this type of selection process must now be carried out statically during test construction. To facilitate this type of aggregation the category attribute can be used to tag the items within the test. See <selection_metadata> for further discussion of this issue.

### 5.29. <outcomes_processing>

This has been replaced by the outcomeProcessing element in version 2 with a multiplicity of [0..1] instead of [*].

### 5.30. <presentation>

This has been replaced by the itemBody in version 2, though the role is roughly equivalent. The term presentation is sometimes treated as synonymous with layout and was therefore changed to reduce the confusion concerning its role in QTI. QTI does not define information for laying out the contents of the itemBody, instead, it supports the class and id attributes on the itemBody, and all its component parts, to enable layout information to be specified by an associated stylesheet.

#### 5.30.1. Attributes: x0, y0, width, height

No longer supported directly in QTI, see Specifying Coordinates for details.

#### 5.30.2. Attributes: label, xml:lang

No change.

### 5.31. <presentation_material>

In version 2 no longer supported at assessmentTest level. should be converted to rubricBlock on assessmentSection level.

### 5.32. <qticomment>

No longer available. Use the metadata in the manifest for this.

### 5.33. <qtimetadata>

No longer available. Use the metadata element in the manifest for this.

### 5.34. <questestinterop>

This element acts as a container for all version 1 QTI ASI objects. This role is now played by a content package. For more information, see the Integration Guide.

### 5.35. <reference>

Replaced by item fragments, see include.

### 5.36. <render_choice>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.36.1. Attribute: shuffle

Now becomes an attribute of the individual interactions, for example, choiceInteraction.

#### 5.36.2. Attribute: minnumber

No longer supported in version 2. It is no longer possible to insist on the minimum number of choices that a user must select.

#### 5.36.3. Attribute: maxnumber

Now becomes an attribute of the individual interactions, renamed as appropriate. For example, the maxChoices attribute of choiceInteraction.

### 5.37. <render_fib>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.37.1. Attributes: encoding, charset

No longer supported in version 2.

#### 5.37.2. Attribute: fibtype

This attribute was largely redundant in version 1 as response_num had a similar Attribute: numtype attribute. In version 2, the response type is determined by the responseDeclaration only.

#### 5.37.3. Attributes: rows, columns, maxchars

Replaced with a single attributed, expectedLength. Note that this is now guidance to the delivery system for the proper sizing of input boxes (where applicable), it is not possible to restrict the number of characters entered by the candidate.

#### 5.37.4. Attribute: prompt

No longer supported in version 2. If control is required over the style of the input box used to enter a response the class attribute should be used to identify a description using an externally defined stylesheet.

#### 5.37.5. Attribute: minnumber, maxnumber

These attribute were problematic in version 1. Support for requiring a minimum number of responses is no longer available in version 2. Maxnumber is replaced by the maxStrings attribute.

### 5.38. <render_hotspot>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.38.1. Attribute: minnumber

No longer supported in version 2. It is no longer possible to insist on the minimum number of points/hotspots that a user must select.

#### 5.38.2. Attribute: maxnumber

Now becomes an attribute of the individual interactions, renamed as appropriate. For example, the maxChoices attribute of hotspotInteraction.

#### 5.38.3. Attribute: showdraw

In the version 1 examples, this attribute heralded a "connect the points" question, though these questions were always bound to a point type response variable with multiple cardinality so there was no information about exactly how the points had been connected, only which points had been connected. In version 2, this type of interaction is called a graphicAssociateInteraction and must be bound to a response with type pair. The showdraw attribute itself therefore has no direct equivalent in version 2.

### 5.39. <render_slider>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.39.1. Attribute: orientation

Equivalent to the orientation attribute of sliderInteraction.

#### 5.39.2. Attributes: lowerbound, upperbound

Equivalent to the lowerBound and upperBound attributes of sliderInteraction.

#### 5.39.3. Attribute: startval

The starting value for a slider is now taken from the defaultValue in the associated responseDeclaration.

#### 5.39.4. Attributes: step, steplabel

Equivalent to step and stepLabel.

#### 5.39.5. Attribute: minnumber, maxnumber

These attributes were meaningless when applied to sliders in version 1 and are no longer supported.

### 5.40. <respcondition>

This element has been replaced with responseCondition which has additional functionality.

#### 5.40.1. Attribute: continue

One of the most significant changes in version 2 is the removal of the continue attribute in favor of an if, else-if, else model within responseCondition. Continue was clearly documented but it was not well implemented, partly because some implementers found the default value unintuitive. If all respcondition elements had continue set to No (the default) then they can all be replaced with a single responseCondition containing a corresponding sequence of responseIf, responseElseIf, responseElseIf, etc. If all respcondition elements had continue set to Yes then the transformation is even simpler, each respcondition corresponding to a individual responseCondition containing a single responseIf. Response processing sections that contain mixtures of Yes and No on their continue attributes are a little more complicated to translate. A No followed by a Yes requires the addition of a responseElse to the responseCondition and the commencement of a nested set of rules. A Yes followed by a No is mercifully simpler as the strategy for the uniform Yes case can be switched to the strategy for the uniform No case at that point.

#### 5.40.2. Attribute: title

No longer supported in version 2.

### 5.41. <response_group>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.41.1. Attributes: ident, cardinality, rtiming

See <response_lid> below for details.

### 5.42. <response_label>

In version 1, response_label was the powerhouse of QTI. It satisfied a different role depending on the combination of response/render elements that contained it. It therefore had many attributes, most of which were ignored in any given situation. In version 2, it has been replaced with an abstract class, choice from which a number of special purpose elements are derived.

In version 1.2.1 of the specification, the role of hotspot label was given to material contained within a response_label being used to define a hotspot. In version 2, this material must be a simple run of text (max 256 characters) and is specified using the hotspotLabel attribute.

#### 5.42.1. Attribute: rshuffle

The sense of this attribute has been inverted and the name has changed in an attempt to reduce confusion with the shuffle attributes on the individual interactions. In version 2, rshuffle is replaced with the fixed attribute.

#### 5.42.2. Attribute: rarea

This attribute has been replaced with the shape attribute of hotspot. Note that the value Ellipse is now deprecated. For compatibility, it has not been removed completely; converting an ellipse into a polygon through rasterization is a non-trivial operation. Circular ellipses should be converted to circles instead.

The coordinates that defined the area were previously supplied as PCDATA within the response_label itself. These are now specified through the coords attribute. Note that coordinates are now space-separated, instead of being comma separated, and that for rectangles they are now given as "xleft yleft xright yright" and for circles (and ellipses) the dimensions are give as radii not diameters. These changes are designed to bring area definitions inline with those used in HTML.

#### 5.42.3. Attribute: rrange

rrange was not consistently documented in version 1 and is no longer supported in version 2. Determining whether or not a value entered by the candidate is acceptable is a job for response processing and the operators defined there should be used instead.

#### 5.42.4. Attribute: labelrefid

This attribute was deprecated in version 1.2 and is no longer supported.

#### 5.42.5. Attribute: ident

In version 2, the identifiers given to choices occupy the same namespace as the identifiers given to the variables themselves and must be unique within each assessmentItem. Therefore, care is needed when converting from version 1. See also the note Attribute: identifier below.

#### 5.42.6. Attribute: match_group, match_max

In version 1, match_group was a comma-separated list of identifiers. In version 2 it follows the XML Schema convention of being a space-separated list of identifiers. Care will be needed when dealing with space padding around the commas, for ease of conversion it is probably safe to assume that the identifiers do not contain spaces. In version 2, they must not contain spaces.

In version 2, matchGroup is an attribute of associableChoice and matchMax is an attribute of those classes derived from it for which it makes sense, for example, simpleAssociableChoice.

### 5.43. <response_lid>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.43.1. Attribute: rcardinality

The cardinality of the response is now indicated by the cardinality attribute of the associated responseDeclaration.

#### 5.43.2. Attribute: rtiming

In version 2, the interaction model for an assessmentItem does not support the concept of individual timing for each interaction. Therefore, the only duration that can be recorded is the amount of time taken for the whole item. For simple items, with only a single interaction, this distinction is not important.

#### 5.43.3. Attribute: identifier

Responses are identified by a unique (within the scope of an assessmentItem) identifier in version 2. This identifier is declared in the responseDeclaration and used to bind an interaction to it. It is also referred to during responseProcessing in access the value of the response in a similar way to version 1.

In version 1, no guidance was given as to what constituted a legal identifier, though a length restriction of 32 characters was specified in the information model. In version 2, identifiers must satisfy the XML NMTOKEN production and must not contain the colon character. Use of the period is deprecated to enable its use as an access character in the future.

The use of standard response processors, new in version 2, also encourages some uniformity in the naming of response variables. For simple items (with only one response) the identifier of the response should be "RESPONSE".

Version 1 was silent on the case sensitivity of identifiers. Version 2 assumes case-sensitivity. It is recommended that identifiers from version 1 be lower-cased when converting to version 2 unless they already match one of the standard variable names.

### 5.44. <response_num>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.44.1. Attribute: numtype

In version 2, decimal and scientific are both treated as being of base-type float. See also the comment concerning Attribute: fibtype above.

#### 5.44.2. Attributes: ident, cardinality, rtiming

See <response_lid> below for details.

### 5.45. <response_str>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.45.1. Attributes: ident, cardinality, rtiming

See <response_lid> below for details.

### 5.46. <response_str>

The response/render model has been replaced in version 2 by responseDeclarations and interactions. For detailed information, see Mapping Response/Render Types to Interactions.

#### 5.46.1. Attributes: ident, cardinality, rtiming

See <response_lid> below for details.

### 5.47. <resprocessing>

This element is now called responseProcessing. Version 2 allows richer processing rules through the use of the new QTI expressions and conditional structures. In version 1, multiple resprocessing sections could be specified, in version 2 only one responseProcessing section can be specified.

#### 5.47.1. Attribute: scoremodel

Originally introduced as a way to differentiate multiple resprocessing sections this attribute was deprecated in version 1.2 and is not needed in version 2.

### 5.48. <rubric>

In version 1, whether or not the item's rubric should be displayed when the item was presented required clarifying. In version 2, rubric has been replaced by rubricBlock which is integrated with the itemBody to make it clearer that it must be.

In version 2 rubric is no longer available on assessmentTest level, at assessmentSection level however the use of a single rubricBlock is allowed.

#### 5.48.1. Attribute: view

The view attribute is unchanged, however, in version 2 there are a smaller number of permitted values: author, candidate, proctor, scorer, tutor. The version 1 values administrator, adminauthority and invigilator are treated in version 2 as proctor. Similarly, assessor and psychometrician are treated in version 2 as scorer. Although in many scenarios it may be possible to distinguish these roles more clearly they do not represent unique roles when controlling access to restricted parts of the itemBody.

### 5.49. <section>

In version 2 each assessmentTest is divided into one or more testParts which may in turn be divided into assessmentSections.

### 5.50. <sectioncontrol>

No longer available in version 2.

### 5.51. <sectionfeedback>

Because outcomeProcessing in version 2 is defined on assessmentTest level, the feedback for individual sections is handled there also.

### 5.52. <sectionpostcondition>

In version 2, the branchRule contains an optional set of rules, evaluated during the test, for setting an alternative target as the next item or section (in nonlinear mode, branch rules are ignored).

### 5.53. <sectionprecondition>

In version 2, the preCondition element within a sectionPart offers an optional set of conditions evaluated during the test, that determine if the item or section is to be skipped (in nonlinear mode, pre-conditions are ignored).

### 5.54. <sectionproc_extension>

No longer available in version 2.

### 5.55. <selection_metadata>

In version 1, this element allowed items to be selected dynamically based on their associated metadata, typically from an externally defined object bank (item pool). In version 2, this type of dynamic test construction is not supported. Tests which used this feature of version 1 can be migrated by making the selection statically at the point at which they are converted to version 2 format. Matching items can be grouped into a section and a selection can be used to to dynamically control the number of them used in any given test. This change can be thought of as focusing the scope of the specification on the output of the test construction process, rather than representing the process itself. In practice, fully automated test construction from a dynamically changing item pool is rarely undertaken so the data model for exchanging sets of rules facilitating it has been removed.

### 5.56. <selection_ordering>

In version 2, the selection element defines the rules used to select which children of the section are to be used for each instance of the test. The ordering contains rules used to determine the order in which the children of the section are to be arranged for each instance of the test. Each child section has its own selection and ordering rules followed before those of its parent. A child section may shuffle the order of its own children while still requiring that they are kept together when shuffling the parent section.

### 5.57. <setvar>

The setvar element has been replaced with the setOutcomeValue response rule.

#### 5.57.1. Attribute: varname

The name of the variable is now identified by the identifier attribute of setOutcomeValue.

#### 5.57.2. setvar.action

In version 2, setOutcomeValue does not support integrated arithmetic. Instead, it sets the outcome variable to the value of an expression. The Add, Subtract, Multiply and Divide actions are therefore replaced with the sum, subtract, product and divide operators respectively. The version 1 behaviour can be obtained by using these operators to combine the variable operator (to obtain the current value of the outcome variable) with an appropriate baseValue.

### 5.58. <solution>

No longer supported in version 2. Material contained in a solution element (which itself was within <itemfeedback>) is simply treated as part of modalFeedback.

#### 5.58.1. <Attribute: feedbackstyle

The style used to present solution material within feedback can be controlled using div and a suitable value for the class attribute, though a vocabulary is beyond the scope of this specification.

### 5.59. <solution_material>

This was a simple grouping element in version 1 and is no longer needed in version 2. See <solution> above for details.

### 5.60. <varequal>

In version 2, the elements used for testing the values of variables have been replaced by a new, more general, expression model. varequal is replaced by a comparison operator and two sub-expressions: a variable operator for accessing the value of the variable and a baseValue operator for specifying the value it should be compared with.

When testing identifiers and integers the match comparison operator is appropriate - it returns true only for exact matches between base values. When testing strings, stringMatch may be more appropriate as it supports case-insensitive matching. For real number comparisons, the equal operator is required.

When the variable being tested has multiple cardinality or ordered cardinality (with no index specified) varequal returns true if the container contains at least one matching value. This functionality is now achieved using the member operator. Note that this operator uses the match form of comparison only.

#### 5.60.1. Attribute: case

When comparing strings, the case-sensitivity of the comparison can be controlled with the caseSensitive attribute.

#### 5.60.2. Attribute: respident

To test the value of a specified variable in version 2, use the variable operator, the respident corresponds to its identifier attribute.

#### 5.60.3. Attribute: index

When testing a response variable of ordered cardinality, the optional index attribute allowed varequal to single out a specific response for the comparison. In version 2, this is achieved with the index operator.

### 5.61. <vargt> and <vargte>

In version 2, the elements used for testing the values of variables have been replaced by a new, more general, expression model. vargt(e) is replaced by a comparison operator and two sub-expressions: a variable operator for accessing the value of the variable and a baseValue operator for specifying the value it should be compared with.

#### 5.61.1. Attributes: respident, index

See <varequal> for details.

### 5.62. <varinside>

In version 1, varinside was used to test a point against an area. This was done during response processing in order to ensure that the hotspots were hidden from the candidate's view during the interaction. In most simple cases the use of varinside can be replaced by declaring an areaMapping in the response declaration. The area mapping allows the (hidden) hot areas of an image to be scored using a standard response processing template. Determining if this scoring method is appropriate, however, is largely a matter of judgment and cannot (easily) be determined automatically. Therefore, varinside does have a directly corresponding operator in version 2: inside.

#### 5.62.1. Attribute: areatype

See Attribute: rarea above for information about the transformation required between the version 1 area model and the version 2 shape model.

#### 5.62.2. Attributes: respident, index

See <varequal> for details.

### 5.63. <varlt> and <varlte>

In version 2, the elements used for testing the values of variables have been replaced by a new, more general, expression model. varlt(e) is replaced by a comparison operator and two sub-expressions: a variable operator for accessing the value of the variable and a baseValue operator for specifying the value it should be compared with.

#### 5.63.1. Attributes: respident, index

See <varequal> for details.

### 5.64. <varsubset>

The role of varsubset was clarified in version 1.2.1 and the examples updated to demonstrate its use in comparing associated pairs in items that used response_grp. Unfortunately, there were no render types that could be unambiguously used in association with response_grp so the use of varsubset was limited. In addition, the semantics post-clarification were identical to varequal excepting the change from simple type to the grp.

In version 2, associations between choices are represented by pair or directedPair and values can be matched using the match operator in exactly the same way as the simple types. (See <varequal> above for more information.)

It is possible that varsubset may have been interpreted as a more general purpose operator for testing that a given set of values is a subset of the response provided by the candidate. In version 2, this is represented by the contains operator.

#### 5.64.1. Attribute: setmatch

The setmatch attribute was not illustrated in the examples distributed with version 1 and may have been used to differentiate between the two cases described above. In version 2, the match operator works just as well for comparing containers (i.e., variables with multiple or ordered cardinality) as it does for simple types. Therefore, there is no need to use an attribute (of contains) to distinguish between exact and partial comparison of containers.

## 6. QTI Metadata Reference

In version 1.2, all <qti_xxxx> metadata elements were deprecated in favor of the use of the <qtimetadata> element. The <qtimetadata> element is a container for all the vocabulary-based QTI-specific meta-data in version 1.2. Because of its flexible nature it is not possible to provide generic guidance on how to convert those to the metadata structures described in Meta-data and Usage Data .

For the <qti_xxxxx> meta-data elements a mapping is provided below.

### 6.1. <qmd_computerscored>

In version 2 this element is not available in the QTI-specific meta-data element and its used is not recommended because it is not possible to clearly define when an item can be computerscored or not.

### 6.2. <qmd_feedbackpermitted>

In version 2 this element is replaced by feedbackType.

### 6.3. <qmd_hintspermitted>

In version 2 this element is no longer available.

### 6.4. <qmd_itemtype>

In version 2 this element is no longer available. Instead the different interactions should be listed in the interactionType element.

### 6.5. <qmd_levelofdifficulty>

In version 2 use of the LOM-defined Difficulty is not recommended.

### 6.6. <qmd_material>

Use the LOM-defined Technical.format instead.

### 6.7. <qmd_maximumscore>

In version 2 each outcome variable in an item has an optional normalMaximum attribute that can be used to define the maximum.

### 6.8. <qmd_renderingtype>

In version 2 no longer available. See Mapping Response/Render Types to Interactions.

### 6.9. <qmd_responsetype>

In version 2 no longer available. See Mapping Response/Render Types to Interactions.

### 6.10. <qmd_scoringpermitted>

In version 2 not available.

### 6.11. <qmd_status>

In version 2 use the LOM-defined Lifecycle.status.

### 6.12. <qmd_timedependence>

In version 2 use timeDependent.

### 6.13. <qmd_timelimit>

This element is no longer available on assessmentItem level, but as timeLimits element in an assessmentTest.

### 6.14. <qmd_toolvendor>

In version 2 this information is split up into the elements toolVendor and toolVersion.

### 6.15. <qmd_topic>

In version 2 use the LOM-defined General.description.

### 6.16. <qmd_typeofsolution>

In version 2 not available.

### 6.17. <qmd_weighting>

In version 2 weights are assigned to an assessmentItem as part of the assessmentItemRef in the assessmentTest.

## 7. Results Reporting Reference

### 7.1. <asi_description>

In version 2, all metadata is stored in the imsmanifest.

### 7.2. <asi_metadata>

In version 2, all metadata is stored in the imsmanifest.

### 7.3. <assessment_result>

Is replaced by testResult.

#### 7.3.1. Attributes: asi_title, ident_ref

In version 2, asi_title is not available and ident_ref can be replaced by the identifier attribute of testResult.

### 7.4. <context>

In version 2 replaced by context which occurs exactly once and can contain one testResult and multiple itemResults.

### 7.5. <control>

In version 1 this contained a record of the feedback mechanisms that were revealed to the participant as a part of the evaluation. It contained a string that summarizes the control switch status.

#### 7.5.1. Attributes: solution_switch, view, hint_switch, feedback_switch

In version 2, there is no alternative available for hint_switch, solution_switch is replaced by showSolution, view is no longer needed, feedback_switch has been replaced by showFeedback.

### 7.6. <correct_response>

Replaced by correctResponse.

### 7.7. <date>

In version 2 each testResult has a single datestamp attribute.

### 7.8. <extension_context>

Not available in version 2.

### 7.9. <extension_grade>

In version 2 not available.

### 7.10. <extension_result>

Not available in version 2.

### 7.11. <extension_score>

In version 2 not available.

### 7.12. <feedback_displayed>

In version 1 this element is used to describe the type of feedback shown to the participant.

#### 7.12.1. Attributes: asi_title, ident_ref, entityref, uri

In version 2 not available as built-in reporting elements.

### 7.13. <generic_identifier>

In version 2 use sessionIdentifier.

### 7.14. <grade_cut>

In version 2 not available.

### 7.15. <item_result>

In version 2 replaced by itemResult.

#### 7.15.1. Attributes: asi_title, ident_ref, entityref, presented

In version 2 asi_title is reported. The identifier attribute is what gets closest to the ident_ref, though it might not be Globally Unique. A sessionStatus < > not initial equals "presented = Yes".

### 7.16. <name>

Version 2 uses LIP for identification purposes; name is part of this structure.

### 7.17. <num_attempts>

In version 2 available as built-in variable.

### 7.18. <num_items>

In version 2 not available as built-in reporting element, but could be reported using an outcomeVariable calculated using the numberSelected expression.

### 7.19. <num_items_attempted>

In version 2 not available as built-in reporting element, but could be reported using an outcomeVariable calculated using the numberResponded expression.

### 7.20. <num_items_presented>

In version 2 not available as built-in reporting element, but could be reported using an outcomeVariable calculated using the numberSelected expression.

### 7.21. <num_sections>

In version 2 not available.

### 7.22. <num_sections_presented>

In version 2 not available.

### 7.23. <objective>

Objectives are stored in the imsmanifest as part of the meta-data.

### 7.24. <qti_comment>

Not available in version 2.

### 7.25. <qti_result_report>

In version 2 the assessmentResult element is the outermost container.

### 7.26. <response>

In version 2 all outcomeVariables, responseVariables and templateVariables are available for the report. Their type is defined in the assessmentItem.

### 7.27. <result>

In version 2 only one testResult element is allowed in a file.

### 7.28. <duration>

In version 2 durations are reported as built-in test-level response variables with name duration.

### 7.29. <score_average>

In version 2 not available, this is considered to be an item statistic. It contains information about the cohort.

### 7.30. <score_cut>

In version 2 replaced by masteryValue.

### 7.31. <score_interpretation>

In version 2 not available. See: outcomeDeclaration Attribute : interpretation [0..1]: string A human interpretation of the variable's value This is not copied across yet / ISSUE: Should this be done?

### 7.32. <score_max>

In version 2 replaced by normalMaximum.

### 7.33. <score_min>

In version 2 replaced by normalMinimum.

### 7.34. <score_normalized>

In version 2 not available, can be calculated as the score for the assessmentItem divided by the normalMaximum.

### 7.35. <score_reliability>

In version 2 not available, this is considered to be an item statistic.

### 7.36. <score_std_error>

In version 2 not available, this is considered to be an item statistic.

### 7.37. <section_result>

There is no section_result element in version 2 even though the results for individual assessmentSections can be reported/calculated if needed.

### 7.38. <summary_result>

Is replaced by a testResult without itemResult information.

## About This Document

Title | IMS Question and Test Interoperability Migration Guide
Editors | Steve Lay (Cambridge Assessment), Pierre Gorissen (SURF)
Version | Public Draft v2.1 (revision 2)
Version Date | 8 June 2006
Status | Public Draft (revision 2) Specification
Summary | This document describes the QTI Migration Guide specification.
Revision Information | 8 June 2006
Purpose | This document has been approved by the IMS Technical Board and is made available for public review and comment.
Document Location | http://www.imsglobal.org/question/qtiv2p1pd2/imsqti_migrv2p1pd2.html

To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=23

### List of Contributors

The following individuals contributed to the development of this document:

Name | Organization
--- | ---
Dick Bacon | University of Surrey
Niall Barr | Question Mark
Lance Blackstone | Pearson VUE
Jeanne Ferrante | ETS
Pierre Gorissen | SURF
Regina Hoag | ETS
Gopal Krishnan | Pearson VUE
Steve Lay | Cambridge Assessment
Rowin Young | CETIS

## Revision History

Version No. | Release Date | Comments
--- | --- | ---
Base Document 2.1 | 14 October 2005 | The first version of the QTI v2.1 specification.
Public Draft 2.1 | 9 January 2006 | The Public Draft v2.1 of the QTI specification.
Public Draft 2.1 (revision 2) | 8 June 2006 | The Public Draft v2.1 (revision 2) of the QTI specification.

IMS Global Learning Consortium, Inc. ("IMS/GLC") is publishing the information contained in this IMS Question and Test Interoperability Migration Guide ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS/GLC makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS/GLC would appreciate receiving your comments and suggestions.
Please contact IMS/GLC through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Question and Test Interoperability Migration Guide Revision: 8 June 2006