ASI XML Binding Specification
Final Specification Version 1.2
|
IMS Question & Test Interoperability: ASI XML Binding Specification Final Specification Version 1.2 |
|
Copyright © 2002 IMS Global Learning Consortium, Inc. All Rights Reserved. The IMS Logo is a trademark of IMS Global Learning Consortium, Inc. Document Name: IMS Question & Test Interoperability: ASI XML Binding Specification Date: 11 February 2002
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 © IMS Global Learning Consortium 2006. All Rights Reserved. If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. 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 Licensee organizations 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 work 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/question/qtiv1p2/qtiv1p2speclicense.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. |
The IMS Question & Test Interoperability (QTI) specification describes a basic structure for the representation of question (item) and test (assessment) data and their corresponding results reports [QTI, 02i]. Therefore, the specification enables the exchange of this item, assessment and results data between Learning Management Systems, as well as content authors and, content libraries and collections. The QTI specification is defined in XML to promote the widest possible adoption. XML is a powerful, flexible, industry standard markup language used to encode data models for Internet-enabled and distributed applications. The QTI specification is extensible and customizable to permit immediate adoption, even in specialized or proprietary systems. Leading suppliers and consumers of learning products, services and content contributed time and expertise to produce this final specification. The QTI specification, like all IMS specifications, does not limit product designs by specifying user interfaces, pedagogical paradigms, or establishing technology or policies that constrain innovation, interoperability, or reuse.
This document describes the implementation of the ASI information model in XML. XML is introduced by outlining XML basics, including a conceptual discussion of the XML schema. The XML schema description of the QTI specification (ims_qtiasi_rootv1p1.xsd and ims_qtiasiv1p2.dtd) defines the Assessment, Section, and Item as XML elements. An example schema for Assessments, Sections, and Items is included, along with details of the meta-data used to catalogue Assessment, Sections, and Items1.
The structure of this document is:
The Question & Test Interoperability data model can be defined as a hierarchy. Hierarchical models are convenient for representing data consisting of many elements and sub-elements. XML is perfectly suited for representing hierarchical models. An XML document is a hierarchy comprised of elements that have contents and attributes.
An element is a component of a document that has been identified in a way a computer can understand. Each element has a tag name. When a tag name is shown as "<TAGNAME>", with less-than and greater-than symbols before and after the tag name, it serves as the start-tag to mark the beginning of an element. When that same tag name has a forward slash "/" added, it serves as an end-tag such as "</TAGNAME>". An element may have contents between its start and end-tags and may have one or more attributes. When an XML element has a start and end-tag (also called an opening and closing tag) with a common name, it is considered to be "well-formed" XML. The contents of an element are placed between the start and end-tags as shown below:
<TAGNAME>contents</TAGNAME>
An element may contain other elements, Parsed Character Data (PCDATA), Character Data (CDATA), or a mixture of PCDATA and elements. The allowable contents of an element are its content model. PCDATA really means any character string that does not contain elements. PCDATA is what the bulk of elements will use between their start and end-tags. CDATA is different in that it is a method for adding any character data that should not be processed. For example, you could add some Java script code instructions using a CDATA section. A CDATA section tells the parser not to look for any markup until after it locates the end of the CDATA section.
An attribute provides additional information about an element. Attributes are a way of attaching characteristics or properties to the elements of a document. An element may have more than one attribute and they are contained within the start tag of an element. Attributes are represented by an attribute name followed by an equal sign and the attribute value in quotation marks:
<timeframe>
<begin restrict="1">1999-07-23</begin>
</timeframe>
In this example the <timeframe> element contains another element, the <begin> element. The <begin> element has one attribute "restrict", with the value 1. The value for the element <begin> is "1999-07-23". These two elements then make up a 'timeframe begin' date.
Each element has a unique name, referred to as the tag name. XML is case-sensitive in its processing of tag names. The IMS Question & Test Interoperability XML Binding Specification adheres to the following tag name rules:
The IMS QTI Results Reporting version 1.2 XML binding is defined in an XML-Schema2. XML-Schema is the primary XML binding control document format of IMS (at present these bindings are working to the May 2001 version of XML Schema). The XML-Schema defines elements, their content models, and attributes. It also defines the standard IMS vocabularies. The XML-Schema defines the element types and attribute groups separately from the elements. This serves three purposes:
|
The XML Schema for the IMS QTI ASI (for version 1.2) is named: |
The tag name, content model, and attributes of elements are defined in a Document Type Definition (DTD) statement. These may exist as an external file or a block of text internal to an XML document. Internal DTDs should be used with care. The DTD defines the elements that may be used, and may define the contents of the elements.
|
This specification defines the external DTD with the file name (for version 1.2): |
Some XML editors may make use of a DTD to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of the DTDs to validate their XML documents to ensure their document is consistent with all of the element names and locations defined in the DTD. An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it. Details of the construction of DTDs are outside the scope of this document, but links to the XML Version 1.0 specification are included in the References section of this document.
The information specifying the order and usage of allowable contents for an element are its content model. The content model is declared in a DTD (see below). The declaration of the content model is of the general form:
<!ELEMENT tagname (Content Model)>
The SHORT element can again serve as an example of how an element is declared with its content model:
<!ELEMENT short (#PCDATA)>
This element will contain character data (#PCDATA) that can be processed. The XML Specification provides more information about the details for creating and interpreting content models.
A list is a repetition of the contents of an element. In XML, this is accomplished by repeating the containing element: for example, the section element contains an element item. Described in the DTD as:
<!ELEMENT section (item*, extension?)>
When instantiated in XML a repeating list of ITEM elements would appear:
<section>
<item> "The first question set."</item>
<item> "The second question set."</item>
</section>
In this example, the element item is repeated. Thus item is the containing element for the repeated contents descriptions. The notation for repetitions of an element in a content model follows the XML specification. An asterisk (*) specifies that none or more repetitions of the element may be included in the XML instantiation whereas a plus (+) specifies that one or more repetitions of the element may be included in the XML instantiation. The extension element is not used - a question mark (?) specifies that none or one repetitions of the element may be included.
An example of how the attributes for the element assessment is declared in a DTD is found below:
<!ELEMENT assessment (description, section+, objectives?, result, extension?)>
<!ATTLIST assessment title CDATA #IMPLIED>
The first line declares that there is an element named assessment that must have the description, section and result elements and is additionally allowed to have objectives and/or extension elements as its contents. The second line begins with "!ATTLIST" to start an attribute list declaration for the assessment element. The word title will serve as the attribute's name. The allowable value for this attribute must be of type CDATA.
At the end of the example above is the term IMPLIED. It is at this location in the attribute declaration, where a default value for an attribute may be specified. It is also possible to use the keyword REQUIRED which would force a TYPE value to be supplied and there would be no default value. In the example above, the IMPLIED designation means that the designer wants to allow users to omit the value for the attribute without forcing a particular default value.
Within the IMS XML binding, the use of attributes is reserved for information about the structure of the relevant data object. This means that an attribute is used to create a specific type of element e.g. the element could be the date and its attribute could be used to define the date as the date of birth.
Some characters used in XML must be escaped when used outside of their XML defined usage as found in Section 2.4 of the XML 1.0 Specification. These characters are ampersand (&), less than (<), greater than (>), apostrophe(') and the double-quotes character("). These characters may be represented using either numeric character references or the strings ",&", "<", ">", "'", and """. Below is a more complete quote from the W3C XML specification:
Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.4 Character Data and Markup
Text consists of intermingled character data and markup. Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, CDATA section delimiters, document type declarations, and processing instructions.
All text that is not markup constitutes the character data of the document.
The ampersand character (&) and the left angle bracket(<) may appear in their literal form only when used as markup delimiters or within a comment, a processing instruction or a CDATA section. They are also legal within the literal entity value of an internal entity declaration; see "4.3.2 Well-Formed Parsed Entities". If they are needed elsewhere, they must be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">" and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.
In the content of elements, character data is any string of characters which does not contain the start delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".
To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as "'", and the double-quote character (") as """.
Questions arise as to whether web-based data transmission tools might inadvertently strip-off or transform some of the white space characters embedded in the Enterprise data transmitted between systems using XML. To eliminate concern about this issue, refer to the following quote from the W3C XML standards, which indicate that all white space must be preserved where it is part of the data.
Quote from Extensible Markup Language (XML) 1.0
W3C Recommendation 10-February-1998
2.10 White Space Handling
In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines, denoted by the non-terminal S in this specification) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.
An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content.
A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose only possible values are "default" and "preserve". For example:
<!ATTLIST poem xml:space (default | preserve)'preserve'>
The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute.
Some providers will find the current element set defined in the IMS QTI specification too restrictive to accomplish their purposes. To ensure extensibility, the specification requires that there be no limit on potential extensions to major elements. An extension is the addition of information to an existing XML structure.
<!ELEMENT resp_extension ANY>
An example of the inclusion of resp_extension in the content model of element presentation is:
<!ELEMENT presentation (render_choice, render_hotspot, resp_extension?)>
The use of the resp_extension element is illustrated as follows:
<presentation>
<render_choice> ... Multiple choice selections ... </render_choice>
<render_hotspot> ... Image hot spot selections ... </render_hotspot>
<resp_extension>
<comment>This is a test to demo extensions</comment>
</resp_extension>
</presentation>
The contents, but not a content model, of an extension must be declared in an internal or external DTD. Many extensions can be created through the use of existing elements. Care must be used with internal DTDs, as they over-ride external DTD declarations. The content of an extension must obey the attribute and content models of the elements employed. New elements that duplicate the definitions of existing elements should not be introduced.
Prefacing the resp_extension element with an appropriate namespace may reference descriptions of extensions. For example, a group such as the Advanced Distributed Learning (ADL) initiative may wish to add the "adl" prefix to an extension element to uniquely identify ADL extensions (the prefix must be declared in the head of the XML instance). The following is an example of this:
<item>
... mandatory elements of item elements here ...
<description lang= " en " >
<short>Military psychometric question </short>
</description>
<adl:resp_extension adl:classification="Not classified">
<adl:comment>Discusses how the questions are constructed for defence posts.
<adl:comment>
</adl:resp_extension>
</item>
This serves to note the entire extension structure. Extensions should always be added at the lowest point (farthest from the root element) in the hierarchy possible, to the degree that the structure defines the meaning of the extension.
This specification defines the XML format using narrative. XML XSDs and XML DTDs that implement this 'abstract' format are provided as informative parts of this specification.
Description: The <questestinterop> element is the outermost container for the QTI contents i.e. the container of the Assessment(s), Section(s) and Item(s).
Multiplicity: The <questestinterop> occurs only once in each XML instance file that is used to support Assessment(s), Section(s) and Item(s).
Description: This element contains the comments that are relevant to the structure as a whole.
Multiplicity: Occurs zero or once within the <questestinterop> element.
Attributes: As per sub-section 3.6.1.
Description: This element contains the Assessment data structure.
Multiplicity: Occurs zero or once within the <questestinterop> element.
Attributes: As per sub-section 3.3.
Description: This element contains the Section data structure.
Multiplicity: Occurs zero or more times within the <questestinterop> element.
Attributes: As per sub-section 3.4.
Description: This element contains the Item data structure.
Multiplicity: Occurs zero or more times within the <questestinterop> element.
Attributes: As per sub-section 3.5.
Description: The Assessment data structure is used to contain the exchange of test data structures. It will always contain at least one Section and may contain meta-data, objectives, rubric control switches, assessment-level processing, feedback and selection and sequencing information for sections.
Multiplicity: Occurs zero or once within the <questestinterop> element.
Description: This element contains the comments that are relevant to the Assessment as a whole.
Multiplicity: Occurs zero or once within the <assessment> element.
Attributes: See sub-section 3.6.1.
Description: The amount of time that a participant is permitted to use in attempting to complete the Assessment.
Multiplicity: Occurs zero or once within the <assessment> element.
Attributes: See sub-section 3.6.2.
Description: The objectives element is used to store the information that describes the educational aims of the Assessment. These objectives can be defined for each of the different 'view' perspectives. This element should not be used to contain information specific to an Assessment because the question-engine may not make this information available to the Item during the actual test.
Multiplicity: Occurs zero or more times within the <assessment> element.
Attributes: See sub-section 3.6.17.
Description: The rubric element is used to contain contextual information that is important to the element e.g. it could contain standard data values that might or might not be useful for answering the question. Different sets of rubric can be defined for each of the possible 'views'.
Multiplicity: Occurs zero or more times within the <assessment> element.
Attributes: See sub-section 3.6.18.
Description: The control switches that are used to enable or disable the display of hints, solutions and feedback within the Assessment.
Multiplicity: Occurs zero or more times within the <assessment> element.
Description: This element contains the comments that are relevant to the Assessment control switches as a whole.
Multiplicity: Occurs zero or once within the <assessmentcontrol> element.
Attributes: See sub-section 3.6.
Description: This is used to contain proprietary alternative Assessment-level processing functionality.
Multiplicity: Occurs zero or once within the <assessment> element.
Description: The container for the Assessment-level feedback that is to be presented as a result of Assessment-level processing of the user's responses.
Multiplicity: Occurs zero or more times within the <assessment> element.
Description: This element contains the comments that are relevant to the Assessment feedback as a whole.
Multiplicity: Occurs zero or once within the <assessfeedback> element.
Attributes: See sub-section 3.6.1.
Description: This element contains the feedback materials that are to be displayed to the participant.
Multiplicity: Occurs zero or more times within the <assessfeedback> element.
Attributes: See sub-section 3.6.3.
Description: This element contains the feedback materials that are to be displayed to the participant.
Multiplicity: Occurs zero or more times within the <assessfeedback> element.
Attributes: See sub-section 3.6.15.
Description: This element is used to 'pull' a Section into the scope. This is used to refer to a Section that has been defined elsewhere but which is to be logically related to this group of Sections.
Multiplicity: Occurs zero or more times within the <assessment> element.
Description: The container for the Section data structure (this is a grouping construct to support the creation of arbitrarily complex hierarchical Assessments).
Multiplicity: Occurs one or more times within the <assessment> element.
Attributes: See sub-section 3.4.
Description: The Section data structure is used to define arbitrarily complex hierarchical section and item data structures. It may contain meta-data, objectives, rubric control switches, assessment-level processing, feedback and selection and sequencing information for sections and items.
Multiplicity: Occurs once or more times within an <assessment> element, zero or more times in the <questestinterop> element and zero or more times within a <section> element.
Description: This element contains the comments that are relevant to the Section as a whole.
Multiplicity: Occurs zero or once within the <section> element.
Attributes: As per sub-section 3.6.1
Description: The amount of time that a participant is permitted to use in attempting to complete the Section.
Multiplicity: Occurs zero or once within the <section> element.
Attributes: See sub-section 3.6.2.
Description: The preconditions that control whether or not the Section is activated.
This is for further study in V2.0.
Multiplicity: Occurs zero or more times within the <section> element.
Description: The postconditions that control whether or not the next Section may be activated.
This is for further study in V2.0.
Multiplicity: Occurs zero or more times within the <section> element.
Description: The objectives element is used to store the information that describes the educational aims of the Section. These objectives can be defined for each of the different 'view' perspectives. This element should not be used to contain information specific to the Items in a Section because the question-engine may not make this information available to the Items during the actual test.
Multiplicity: Occurs zero or more times within the <section> element.
Attributes: See sub-section 3.6.17.
Description: The rubric element is used to contain contextual information that is important to the element e.g. it could contain standard data values that might or might not be useful for answering the question. Different sets of rubric can be defined for each of the possible 'views'.
Multiplicity: Occurs zero or more times within the <section> element.
Attributes: See sub-section 3.6.18.
Description: The control switches that are used to enable or disable the display of hints, solutions and feedback within the Section.
Multiplicity: Occurs zero or more times within the <section> element.
Description: This is used to contain proprietary alternative Section-level processing functionality.
Multiplicity: Occurs zero or once within the <section> element.
Description: The container for the Section-level feedback that is to be presented as a result of Section-level processing of the user's responses.
Multiplicity: Occurs zero or more times within the <section> element.
Description: This element contains the comments that are relevant to the Section feedback as a whole.
Multiplicity: Occurs zero or once within the <sectionfeedback> element.
Attributes: As per sub-section 3.6.1.
Description: This element contains the feedback materials that are to be displayed to the participant.
Multiplicity: Occurs zero or more times within the <sectionfeedback> element.
Attributes: See sub-section 3.6.3.
Description: This element contains the block/paragraph structured feedback materials that are to be displayed to the participant.
Multiplicity: Occurs zero or more times within the <sectionfeedback> element.
Attributes: See sub-section 3.6.15.
Description: This element is used to 'pull' a Section into the scope. This is used to refer to a Section that has been defined elsewhere but which is to be logically related to this group of Sections.
Multiplicity: Occurs zero or more times within the <section> element.
Description: The container for the Section data structure (this is a grouping construct to support the creation of arbitrarily complex hierarchical Assessments).
Multiplicity: Occurs one or more times within the <section> element.
Attributes: See sub-section 3.4.
Description: This element is used to 'pull' an Item into the scope. This is used to refer to a Item that has been defined elsewhere but which is to be logically related to this group of Items.
Multiplicity: Occurs zero or more times within the <section> element.
Description: The Item is the smallest unit data structure that can be exchanged using the QTI specification. Each Item consists of five distinct parts, namely: objectives - the materials used to describe the objectives with respect to each view; rubric - the materials used to define the context of the Item and available for each view; presentation - the instructions describing the nature of the question to be asked; resprocessing - the instructions to be followed when analyzing the responses to create a corresponding score and feedback; itemfeedback - the materials to be presented as feedback to the entered response.
Multiplicity: Occurs zero or more times within the <section> element.
Attributes: See sub-section 3.5.
Description: Each Item consists of five distinct parts, namely: objectives - the materials used to describe the objectives with respect to each view; rubric - the materials used to define the context of the Item and available for each view; presentation - the instructions describing the nature of the question to be asked; resprocessing - the instructions to be followed when analyzing the responses to create a corresponding score and feedback; itemfeedback - the materials to be presented as feedback to the entered response.
Multiplicity: Occurs one or more times within the <questestinterop> element.
Description: This element contains the comments that are relevant to the Item as a whole.
Multiplicity: Occurs zero or once within the <item> element.
Attributes: See sub-section 3.6.1.
Description: The amount of time that a participant is permitted to use in attempting to complete the Item.
Multiplicity: Occurs zero or once within the <item> element.
Attributes: See sub-section 3.6.2.
Description: The itemmetadata element contains all of the QTI-specific meta-data to be applied to the Item. This meta-data can consist of either entries defined using an external vocabulary or the individually named entries.
Multiplicity: Occurs zero or once within the <item> element.
Description: The container for the definition of QTI-specific meta-data entries that are defined using an external vocabulary.
Multiplicity: Occurs zero or more times within the <item> element.
Attributes: As per sub-section 3.6.16.
Description: Whether or not the Item can be computer scored.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: Indicates whether or not feedback is available within the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: Indicates whether or not hints are available within the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The type of Item available.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Description: The educational level for which the Item is intended.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The type of material content used within the Item.
Multiplicity: Occurs zero or more times within the <itemmetadata> element.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Description: The maximum score possible from the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The type of rendering used within the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or more times within the <itemmetadata> element.
Description: The class of response expected for the Item.
Multiplicity: Occurs zero or more times within the <itemmetadata> element.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Description: Indicates whether or not scoring is available within the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: Indicates whether or not solutions are available within the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The status of the Item.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Description: Whether or not the responses are time dependent.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The number of minutes to be permitted for the completion of the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The name of the vendor of the tool creating the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The brief description of the topic covered by the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The type of solution available in the Item.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The weighting to be applied to the scores allocated to this Item before aggregations with other scores.
This element is deprecated and the <qtimetadata> mechanism should be used instead.
Multiplicity: Occurs zero or once within the <itemmetadata> element.
Description: The preconditions that control whether or not the Item is activated.
This is for further study in V2.0.
Multiplicity: Occurs zero or more times within the <item> element.
Description: The postconditions that control whether or not the next Item may be activated.
This is for further study in V2.0.
Multiplicity: Occurs zero or more times within the <item> element.
Description: The objectives element is used to store the information that describes the educational aims of the Item. These objectives can be defined for each of the different 'view' perspectives. This element should not be used to contain information specific to an Item because the question-engine may not make this information available to the Item during the actual test.
Multiplicity: Occurs zero or more times within the <item> element.
Attributes: See sub-section 3.6.17.
Description: The control switches that are used to enable or disable the display of hints, solutions and feedback within the Item.
Multiplicity: Occurs zero or more times within the <item> element.
Description: This element contains the comments that are relevant to the Item control switches as a whole.
Multiplicity: Occurs zero or once within the <itemcontrol> element.
Attributes: As per sub-section 3.6.1
Description: The itemrubric element is used to contain contextual information that is important to the element e.g. it could contain standard data values that might or might not be useful for answering the question. Different sets of rubric can be defined for each of the possible 'views'. This approach is deprecated in favour of the <rubric> element.
Multiplicity: Occurs zero or more times within the <item> element.
Description: The rubric element is used to contain contextual information that is important to the element e.g. it could contain standard data values that might or might not be useful for answering the question. Different sets of rubr
