![]() |
IMS Question and Test Interoperability Assessment Test, Section, and Item Information ModelVersion 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 Assessment Test,
Section, and Item Information Model
Revision: 8 June 2006
| Date Issued: |
8 June 2006 |
| Latest version: |
http://www.imsglobal.org/question/qtiv2p1pd2/imsqti_infov2p1pd2.html |
| Register comments or implementations: |
http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=23 |
|
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/question/qtiv2p1pd2/qtiv2p1pd2speclicense.html. 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 web site: http://www.imsglobal.org/specificationdownload.cfm. This document may be copied and furnished to others by Licensee organizations registered on the IMS web site 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 web site: http://www.imsglobal.org/specificationlicense.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. |
|
An adaptive item is an Item that adapts either its appearance, its scoring (Response Processing) or both in response to each of the candidate's Attempts. For example, an adaptive item may start by prompting the candidate with a box for free-text entry but, on receiving an unsatisfactory answer, present a simple choice Interaction instead and award fewer marks for subsequently identifying the correct response. Adaptivity allows authors to create items for use in formative situations which both help to guide candidates through a given task while also providing an Outcome that takes into consideration their path, enabling better subsequent content sequencing decisions to be made.
An Adaptive Test is a Test that varies the items presented to the candidate based on the responses given on items already completed. This specification only supports very limited adaptivity through the use of pre-conditions and branching. See Pre-conditions and Branching.
Assessment is the process of measuring some aspect of a candidate. In the context of this specification, Assessment is carried out using Tests and the term Assessment is treated as being equivalent to an Assessment Test.
An Assessment Test is an organized collection of Items that are used to determine the values of the outcomes (e.g., level of mastery) when measuring the performance of a candidate in a particular domain. An Assessment test contains all of the necessary instructions to enable the sequencing of the items and the calculation of the outcome values (e.g., the final test score).
An Assessment Variable is a variable used to maintain a value associated with an Item Session or Test Session. For example, the value of a Response given by the candidate or the value of an Outcome for an individual item or an entire test.
A system for the administration and delivery of assessments to candidates. See also Delivery Engine.
An attempt (at an Item) is the process by which the Candidate interacts with an item in one or more Candidate Sessions, possibly assigning values to or updating the associated Response Variables.
A system used by authors for creating and editing Items and Assessments.
A base-type is a predefined data type that defines a value set from which values for Item Variables are drawn. These values are indivisible with respect to the runtime model described by this specification.
A basic item is an Item that contains one and only one Interaction.
A person that participates in a test, assessment, or exam by answering questions. See also the actor candidate.
A period of time during which the candidate is interacting with the Item as part of an Attempt. An attempt may consist of more than one candidate session. For example, candidates that are not sure of the answer to one question may navigate to a second question in the same test and return to the first one later. When they leave the first question they terminate the candidate session but they do not terminate the Attempt. The attempt is simply suspended until a subsequent candidate session concludes it, triggering Response Processing and (possibly) Feedback.
A cloning engine is a system for creating multiple similar items (Item Clones) from an Item Template.
A composite item is an Item that contains more than one Interaction.
A container is an aggregate data type that can contain multiple values of the primitive Base-types. Containers may be empty.
The process that coordinates the rendering and delivery of the Item(s) and the evaluation of the responses to produce scores and Feedback.
Any material presented to the candidate conditionally based on the value of an Outcome Variable. See also Integrated Feedback, Modal Feedback, and Test Feedback.
Interactions allow the candidate to interact with the item. Through an interaction, the candidate selects or constructs a response. See also the class interaction.
Integrated feedback is the name given to Feedback that is integrated into the item's itemBody. Unlike Modal Feedback the candidate is free to update their responses while viewing integrated feedback.
The smallest exchangeable assessment object within this specification. An item is more than a 'Question' in that it contains the question and instructions to be presented, the responseProcessing to be applied to the candidates response(s) and the Feedback that may be presented (including hints and solutions). In this specification items are represented by the assessmentItem class and the term assessment item is used interchangeably for item.
Item Clones are items created by an Item Template.
An Item Fragment is part of an item managed independently of items that include it. See also Item Set.
An item session is the accumulation of all the Attempts at a particular item made by a candidate.
An Item Set is a set of items that share some common characteristic. For example, all items in the set may be introduced by the same Item Fragment, in which case the fragment is often referred to as the set leader.
Item templates are templates that can be used for producing large numbers of similar Items. Such items are often called cloned items. Item templates can be used to produce items by a special purpose Cloning Engine or, where Delivery Engines support them, be used directly to produce a dynamically chosen clone at the start of an Item Session. Each item cloned from an item template is identical except for the values given to a set of Template Variables. An item is therefore an item template if it declares one or more template variables and contains a set of Template Processing rules for assigning them values.
A variable that records part of the state of an Item Session. The candidate's responses and any outcomes assigned by Response Processing are stored in item variables. Item variables are also used to define Item Templates. Item variables are a special kind of Assessment Variable.
Material means all static text, image, or media objects that are intended for the user rather than being interpreted by a processing system. Interactions are not material.
Modal feedback is the name give to Feedback that is presented to the candidate on its own, as opposed to being integrated into the item's itemBody.
A multiple response is a Response Variable that is a Container for multiple values all drawn from the value set defined by one of the Base-types. A multiple response is processed as an unordered list of these values. The list may be empty.
An non-adaptive item is an Item that does not adapt itself in response to the candidate's Attempts.
An object bank is a collection of objects used in assessment, including Items, Item Fragments, Tests, or parts of tests. Object banks are not represented directly in this information model. See Integration Guide for information about how to package assessment objects for interchange.
An ordered response is a Response Variable that is a Container for multiple values all drawn from the value set defined by one of the Base-types. An ordered response is processed as an ordered list (sequence) of values. The list may be empty.
The result of an Assessment Test or Item. An outcome is represented by one or more Outcome Variables.
The process by which the values of item Outcomes (or Responses) are aggregated to make test outcomes.
Outcome variables are declared by outcome declarations. Their value is set either from a default given in the declaration itself or by a response rule encountered during Response Processing (for Item outcomes) or Outcome Processing (for Test outcomes). See also the class outcomeDeclaration.
A group of related items transported together with meta-data that describes the group as a whole. A pool is a special case of an Object Bank.
The data provided by the candidate through interaction with an item, or part of an item. The values of candidate responses are represented by Response Variables.
The process by which the values of Response Variables are judged (scored) and the values of item Outcomes are assigned.
Response variables are declared by response declarations and bound to Interactions in the Item body, they record the candidate's responses. See also the class responseDeclaration
The part of the assessment system that handles the scoring based on the Candidate's responses and the Response Processing rules.
The name given to feedback that is presented to the candidate conditionally based on the value of test Outcomes.
A single response is a Response Variable that can take a single value from the set of values defined by one of the Base-types.
A set of rules used to set the values of the Template Variables, typically involving some random process, and thereby select the specific clone to be used for an Item Session.
Template variables are declared by template declarations and used to record the values required to instantiate an item template. The values determine which clone from the set of similar items defined by an Item Template is being used for a given Item Session.
A Test Fragment is part of a test managed independently of the tests that include it.
A Test Report is a report on the Test Session.
A test session is the interaction of a candidate with a Test and the items it contains.
A time dependent item is an Item that records the accumulated elapsed time for the Candidate Sessions in a Response Variable that is used during Response Processing.
A time independent item is an Item that does not use the accumulated elapsed time during Response Processing. In practice, this information may be collected by a Delivery Engine and may still be reported as part of a Test Report.
In this specification an assessment item encompasses the information that is presented to a candidate and information about how to score the item. Scoring takes place when candidate responses are transformed into outcomes by response processing rules. It is sometimes desirable to have several different items that appear the same to the candidate but which are scored differently. In this specification, these are distinct items by definition and must therefore have distinct identifiers. To help facilitate the exchange of items that share significant parts of their presentation this specification supports the inclusion of separately managed item fragments (see Item and Test Fragments) in the itemBody.
Attribute
: identifier [1]: string
The principle identifier of the item. This identifier must have a
corresponding entry in the item's meta-data. See Meta-data and Usage Data
for more information.
Attribute
: title [1]: string
The title of an assessmentItem
is intended to enable the item to be selected in situations where the
full text of the itemBody
is not available, for example when a candidate is browsing a set of
items to determine the order in which to attempt them. Therefore,
delivery engines may reveal the title to candidates at any time but are
not required to do so.
Attribute
: label [0..1]: string256
Attribute
: lang [0..1]: language
Attribute
: adaptive [1]: boolean
= false
Items are classified into Adaptive
Items and Non-adaptive Items.
Attribute
: timeDependent [1]: boolean
Attribute
: toolName [0..1]: string256
The tool name attribute allows the tool creating the item to identify
itself. Other processing systems may use this information to interpret
the content of application specific data, such as labels on the elements of the
item's itemBody.
Attribute
: toolVersion [0..1]: string256
The tool version attribute allows the tool creating the item to
identify its version. This value must only be interpreted in the
context of the toolName
Contains
: responseDeclaration [*]
Contains
: outcomeDeclaration [*]
Contains
: templateDeclaration [*]
Contains
: templateProcessing [0..1]
Contains
: stylesheet [0..*]
Contains
: itemBody [0..1]
Contains
: responseProcessing [0..1]
The discussion that follows forms part of this specification's requirements on Delivery Engines.

Figure 4.1 Lifecycle of an Item Session.
The session starts when the associated item first becomes eligible for delivery to the candidate. The item session's state is then maintained and updated in response to the actions of the candidate until the session is over. At any time the state of the session may be turned into an itemResult. A delivery system may also allow an itemResult to be used as the basis for a new session in order to allow a candidate's responses to be seen in the context of the item itself (and possibly compared to a solution) or even to allow a candidate to resume an interrupted session at a later time.
The initial state of an item session represents the state after it has been determined that the item will be delivered to the candidate but before the delivery has taken place.
In a typical non-Adaptive Test the items are selected in advance and the candidate's interaction with all items is reported at the end of the test session, regardless of whether or not the candidate actually attempted all the items. In effect, item sessions are created in the initial state for all items at the start of the test and are maintained in parallel. In an Adaptive Test the items that are to be presented are selected during the session based on the responses and outcomes associated with the items presented so far. Items are selected from a large pool and the delivery engine only reports the candidate's interaction with items that have actually been selected.
A candidate's interaction with an item is broken into 0 or more attempts. During each attempt the candidate interacts with the item through one or more candidate sessions. At the end of a candidate session the item may be placed into the suspended state ready for the next candidate session. During a candidate session the item session is in the interacting state. Once an attempt has ended response processing takes place, after response processing a new attempt may be started.
For non-adaptive items, response processing typically takes place a limited number of times, usually only once. For adaptive items, no such limit is required because the response processing adapts the values it assigns to the outcome variables based on the path through the item. In both cases, each invocation of response processing occurs at the end of each attempt. The appearance of the item's body, and whether any modal feedback is shown, is determined by the values of the outcome variables.
When no more attempts are allowed the item session passes into the closed state. Once in the closed state the values of the response variables are fixed. A delivery system or reporting tool may still allow the item to be presented after it has reached the closed state. This type of presentation takes place in the review state, summary feedback may also be visible at this point if response processing has taken place and set a suitable outcome variable.
Finally, for systems that support the display of solutions, the item session may pass into the solution state. In this state, the candidate's responses are temporarily replaced by the correct values supplied in the corresponding responseDeclarations (or NULL if none was declared).
When items are referenced as part of a test, the test may impose constraints on how many attempts and which states are allowed. These constraints can be specified for individual items, for whole sections, or for an entire testPart. By default, a setting at testPart level affects all items in that part unless the setting is overridden at the assessmentSection level or ultimately at the individual assessmentItemRef. The defaults given below are used only in the absence of any applicable constraint.
Attribute
: maxAttempts [0..1]: integer
For non-adaptive items, maxAttempts controls the
maximum number of attempts allowed in the given test context. Normally
this is 1 as the scoring rules for non-adaptive items are the same for
each attempt. A value of 0 indicates no limit. If it is unspecified it
is treated as 1 for non-adaptive items. For adaptive items, the value
of maxAttempts is ignored as the number of
attempts is limited by the value of the completionStatus
built-in outcome variable.
A value of maxAttempts greater than 1, by definition, indicates that any applicable feedback must be shown. This applies to both Modal Feedback and Integrated Feedback where applicable. However, once the maximum number of allowed attempts have been used (or for adaptive items, completionStatus has been set to completed) whether or not feedback is shown is controlled by the showFeedback constraint.
Attribute
: showFeedback [0..1]: boolean
This constraint affects the visibility of feedback after
the end of the last attempt. If it is false then
feedback is not shown. This includes both Modal
Feedback and Integrated
Feedback even if the candidate has access to the
review state. The default is false.
Attribute
: allowReview [0..1]: boolean
This constraint also applies only after the end
of the last attempt. If set to true the item
session is allowed to enter the review state
during which the candidate can review the itemBody
along with the responses they gave, but cannot update or resubmit them.
If set to false the candidate can not
review the itemBody or
their responses once they have submitted their last attempt. The
default is true.
If the review state is allowed, but feedback is not, delivery systems must take extra care not to show integrated feedback that resulted from the last attempt as part of the review process. Feedback can however take the form of hiding material that was previously visible, as well as the more usual form of showing material that was previously hidden.
To resolve this ambiguity, for non-adaptive items the absence of feedback is defined to be the version of the itemBody displayed to the candidate at the start of each attempt. In other words, with the visibility of any integrated feedback determined by the default values of the outcome variables and not the values of the outcome variables updated by the invocation of response processing.
For Adaptive Items the situation is complicated by the iterative nature of response processing which makes it hard to identify the appropriate state in which to place the item for review. To avoid requiring delivery engines to cache the values of the outcome variables the setting of showFeedback should be ignored for adaptive items when allowReview is true. When in the review state, the final values of the outcome variables should be used to determine the visibility of integrated feedback.
Attribute
: showSolution [0..1]: boolean
This constraint controls whether or not the system may provide the
candidate with a way of entering the solution
state. The default is false.
Attribute
: allowComment [0..1]: boolean
Some delivery systems support the capture of candidate comments. The
comment is not part of the assessed responses but provides feedback
from the candidate to the other actors in the assessment process. This
constraint controls whether or not the candidate is allowed to provide
a comment on the item during the session.
Attribute
: allowSkipping [0..1]: boolean
= true
An item is defined to be skipped if the candidate has not provided any
response. In other words, all response variables
are submitted with their default value or are NULL. This definition is
consistent with the numberResponded
operator available in outcomeProcessing.
If false, candidates are not allowed to skip the
item, or in other words, they are not allowed to submit the item until
they have provided a non-default value for at least one of the response
variables. By definition, an item with no response variables cannot be
skipped. The value of this attribute is only applicable when the item
is in a testPart with individual submission mode.
Note that if allowSkipping is true delivery
engines must ensure that the candidate can choose to submit no
response, for example, through the provision of a "skip" button.
Attribute
: validateResponses [0..1]: boolean
This attribute controls the behavior of delivery engines when the
candidate submits an invalid response. An invalid
response is defined to be a response which does not satisfy the
constraints imposed by the interaction with which it is associated. See
interaction for more
information. When validateResponses is turned on (true)
then the candidates are not allowed to submit the item until they have
provided valid responses for all interactions. When turned off (false)
invalid responses may be accepted by the system. The value of this
attribute is only applicable when the item is in a testPart with individual submission mode.
(See Navigation and Submission.)

Figure 5.1 Variable Declarations.
Item variables are declared by variable declarations. All variables must be declared except for the built-in session variables referred to below which are declared implicitly and must not be declared. The purpose of the declaration is to associate an identifier with the variable and to identify the runtime type of the variable's value.
An item variable may have no value at all, in which case it is said to have the special value NULL. For example, if the candidate has not yet had an opportunity to respond to an interaction then any associated response variable will have a NULL value. Empty containers and empty strings are always treated as NULL values.
Attribute
: identifier [1]: identifier
The identifiers of the built-in session variables are reserved. They
are completionStatus, numAttempts
and duration. All item variables declared in an
item share the same namespace. Different items have different
namespaces.
Attribute
: cardinality [1]: cardinality
Each variable is either single valued or multi-valued. Multi-valued
variables are referred to as containers and come in ordered, unordered
and record types. See cardinality
for more information.
Attribute
: baseType [0..1]: baseType
The value space from which the variable's value can be drawn (or in the
case of containers, from which the individual values are drawn) is
identified with a baseType.
The baseType selects one of a small set of predefined types that are
considered to have atomic values within the runtime data model.
Variables with record
cardinality have no base-type.
Contains
: defaultValue [0..1]
An optional default value for the variable. The point at which a
variable is set to its default value varies depending on the type of
item variable.
A class that can represent a single value of any baseType in variable declarations and result reports. The base-type is defined by the baseType attribute of the declaration except in the case of variables with record cardinality.
Attribute
: fieldIdentifier [0..1]: identifier
This attribute is only
used for specifying the field identifier for a value that forms part of
a record.
Attribute
: baseType [0..1]: baseType
This attribute is only
used for specifying the base-type of a value that forms part of a record.
Attribute
: interpretation [0..1]: string
A human readable interpretation of the default value.
Contains
: value [1..*]
An expression or itemVariable can either be single-valued or multi-valued. A multi-valued expression (or variable) is called a container. A container contains a list of values, this list may be empty in which case it is treated as NULL. All the values in a multiple or ordered container are drawn from the same value set, however, containers may contain multiple occurrences of the same value. In other words, [A,B,B,C] is an acceptable value for a container. A container with cardinality multiple and value [A,B,C] is equivalent to a similar one with value [C,B,A] whereas these two values would be considered distinct for containers with cardinality ordered. When used as the value of a response variable this distinction is typified by the difference between selecting choices in a multi-response multi-choice task and ranking choices in an order objects task. In the language of [ISO11404] a container with multiple cardinality is a "bag-type", a container with ordered cardinality is a "sequence-type" and a container with record cardinality is a "record-type".
The record container type is a special container that contains a set of independent values each identified by its own identifier and having its own base-type. This specification does not make use of the record type directly however it is provided to enable customInteractions to manipulate more complex responses and customOperators to return more complex values.
identifier
The set of identifier values is the same as the set of values defined
by the identifier
class.
boolean
The set of boolean values is the same as the set of values defined by
the boolean
class.
integer
The set of integer values is the same as the set of values defined by
the integer
class.
float
The set of float values is the same as the set of values defined by the
float class.
string
The set of string values is the same as the set of values defined by
the string
class.
duration
A duration value specifies a distance (in time) between two time
points. In other words, a time period as defined by [ISO8601]. Durations are
measured in seconds and may have a fractional part.
file
A file value is any sequence of octets (bytes) qualified by a
content-type and an optional filename given to the file (for example,
by the candidate when uploading it as part of an interaction). The content
type of the file is one of the MIME types defined by [RFC2045].
uri
A URI value is a Uniform Resource Identifier as defined by [URI].
A special class used to create a mapping from a source set of any baseType (except file and duration) to a single float. Note that mappings from values of base type float should be avoided due to the difficulty of matching floating point values, see the match operator for more details. When mapping containers the result is the sum of the mapped values from the target set. See mapResponse for details.
Attribute
: lowerBound [0..1]: float
The lower bound for the result of mapping a container. If unspecified
there is no lower-bound.
Attribute
: upperBound [0..1]: float
The upper bound for the result of mapping a container. If unspecified
there is no upper-bound.
Attribute
: defaultValue [1]: float
= 0
The default value from the target set to be used when no explicit
mapping for a source value is given.
Contains
: mapEntry [1..*]
The map is defined by a set of mapEntries, each of which maps a single
value from the source set onto a single float.
Attribute
: mapKey [1]: valueType
The source value
Attribute
: mappedValue [1]: float
The mapped value
Class
: responseDeclaration (variableDeclaration)
assessmentItemResponse variables are declared by response declarations and bound to interactions in the itemBody.
At runtime, response variables are instantiated as part of an item session. Their values are always initialized to NULL (no value) regardless of whether or not a default value is given in the declaration. A response variable with a NULL value indicates that the candidate has not offered a response, either because they have not attempted the item at all or because they have attempted it and chosen not to provide a response.
If a default value has been provided for a response variable then the variable is set to this value at the start of the first attempt. If the candidate never attempts the item, in other words, the item session passes straight from the initial state to the closed state without going through the interacting state, then the response variable remains NULL and the default value is never used.
Implementors of Delivery Engines should take care when implementing user interfaces for items with default response variable values. If the associated interaction is left in the default state (i.e., representing the default value) then it is important that the system is confident that the candidate intended to submit this value and has not simply failed to notice that a default has been provided. This is especially true if the candidate's attempt ended due to some external event, such as running out of time. The techniques required to distinguish between these cases are an issue for user interface design and are therefore out of scope for this specification.
Contains
: correctResponse [0..1]
A response declaration may assign an optional correctResponse. This
value may indicate the only possible value of the response variable to
be considered correct or merely just a correct
value. For responses that are being measured against a more complex
scale than correct/incorrect this value should be set to the (or an)
optimal value. Finally, for responses for which no such optimal value
is defined the correctResponse must be omitted. If a delivery system
supports the display of a solution then it should display the correct
values of responses (where defined) to the candidate. When correct
values are displayed they must be clearly distinguished from the
candidate's own responses (which may be hidden completely if necessary).
Contains
: mapping [0..1]
The mapping provides a mapping from the set of base values to a set of
numeric values for the purposes of response processing. See mapResponse for information
on how to use the mapping.
Contains
: areaMapping [0..1]
The areaMapping, which may only be present in declarations of variables
with baseType point,
provides an alternative form of mapping which tests against areas of
the coordinate space instead of mapping single values (i.e., single
points).
Attribute
: interpretation [0..1]: string
A human readable interpretation of the correct value.
Contains
: value [1..*]
A special class used to create a mapping from a source set of point values to a target set of float values. When mapping containers, the result is the sum of the mapped values from the target set. See mapResponsePoint for details. The attributes have the same meaning as the similarly named attributes on mapping.
Attribute
: lowerBound [0..1]: float
Attribute
: upperBound [0..1]: float
Attribute
: defaultValue [1]: float
= 0
Contains
: areaMapEntry [1..*] {ordered}
The map is defined by a set of areaMapEntries, each of which maps an
area of the coordinate space onto a single float. When mapping points
each area is tested in turn, with those listed first taking priority in
the case where areas overlap and a point falls in the intersection.
Attribute
: shape [1]: shape
The shape of the area.
Attribute
: coords [1]: coords
The size and position of the area, interpreted in conjunction with the
shape.
Attribute
: mappedValue [1]: float
The mapped value
There are two built-in response variables, numAttempts and duration that are declared implicitly and must not appear in a responseDeclaration.
All Delivery Engines must maintain the value of numAttempts. This is a single integer that records the number of attempts at each item the candidate has taken. The value defaults to 0 initially and then increases by 1 at the start of each attempt.
Systems that support Time Dependent Items must also maintain the value of duration. The duration is defined as being a single float that records the accumulated time (in seconds) of all Candidate Sessions for all Attempts. In other words the time between the beginning and the end of the item session minus any time the session was in the suspended state. The resolution of the duration must be at least 1s and should be 0.1s or smaller. If the resolution is denoted by epsilon then each value of duration represents the range of values duration<=t<duration+epsilon. In other words, duration values are truncated.
The value of duration for items that are not time dependent must not be used in any item or test-level expression, though systems should still report it in itemResults when it is known.
Class
: outcomeDeclaration (variableDeclaration)
assessmentTest, assessmentItemOutcome variables are declared by outcome declarations. Their value is set either from a default given in the declaration itself or by a responseRule during responseProcessing.
Items that declare a numeric outcome variable representing the candidate's overall performance on the item should use the outcome name 'SCORE' for the variable.
At runtime, outcome variables are instantiated as part of an item session. Their values may be initialized with a default value and/or set during responseProcessing. If no default value is given in the declaration then the outcome variable is initialized to NULL unless the outcome is of a numeric type (integer or float) in which case it is initialized to 0.
For Non-adaptive Items, the values of the outcome variables are reset to their default values prior to each invocation of responseProcessing. For Adaptive Items the outcome variables retain the values that were assigned to them during the previous invocation of response processing. For more information, see Response Processing.
Attribute
: view [*]: view
The intended audience for an outcome variable can be set with the view
attribute. If no view is specified the outcome is treated as relevant
to all views. Complex items, such as adaptive
items or complex templates, may declare outcomes that are of no
interest to the candidate at all, but are merely used to hold
intermediate values or other information useful during the item or test
session. Such variables should be declared with a view of author (for item outcomes) or
testConstructor (for
test outcomes). Systems may exclude outcomes from result reports on the
basis of their declared view if appropriate.
Attribute
: interpretation [0..1]: string
A human interpretation of the variable's value.
Attribute
: longInterpretation [0..1]: uri
An optional link to an extended interpretation of the outcome
variable's value.
Declared outcomes with numeric types should indicate their range of possible values using normalMaximum and normalMinimum, especially if this range differs from [0,1].
Attribute
: normalMaximum [0..1]: float
The normalMaximum attribute optionally defines the maximum magnitude
of numeric outcome variables, it must be a positive value. If given,
the outcome's value can be divided by normalMaximum and then truncated
(if necessary) to obtain a normalized score in the range [-1.0,1.0].
normalMaximum has no affect on responseProcessing
or the values that the outcome variable itself can take.
Attribute
: normalMinimum [0..1]: float
The normalMinimum attribute optionally defines the minimum value of
numeric outcome variables, it may be negative.
Attribute
: masteryValue [0..1]: float
The masteryValue attribute optionally defines a value for numeric
outcome variables above which the aspect being measured is considered
to have been mastered by the candidate.
Contains
: lookupTable [0..1]
interpolationTable, matchTableoutcomeDeclarationAn abstract class associated with an outcomeDeclaration used to create a lookup table from a numeric source value to a single outcome value in the declared value set. A lookup table works in the reverse sense to the similar mapping as it defines how a source numeric value is transformed into the outcome value, whereas a (response) mapping defines how the response value is mapped onto a target numeric value.
The transformation takes place using the lookupOutcomeValue rule within responseProcessing or outcomeProcessing.
Attribute
: defaultValue [0..1]: valueType
The default outcome value to be used when no matching table entry is
found. If omitted, the NULL value is used.
A matchTable transforms a source integer by finding the first matchTableEntry with an exact match to the source.
Contains
: matchTableEntry [1..*]
Attribute
: sourceValue [1]: integer
The source integer that must be matched exactly.
Attribute
: targetValue [1]: valueType
The target value that is used to set the outcome when a match is found.
An interpolationTable transforms a source float (or integer) by finding the first interpolationTableEntry with a sourceValue that is less than or equal to (subject to includeBoundary) the source value.
For example, an interpolation table can be used to map a raw numeric score onto an identifier representing a grade. It may also be used to implement numeric transformations such as those from a simple raw score to a value on a calibrated scale.
Attribute
: sourceValue [1]: float
The lower bound for the source value to match this entry.
Attribute
: includeBoundary [0..1]: boolean
= true
Determines if an exact match of sourceValue
matches this entry. If true, the default, then an
exact match of the value is considered a match of this entry.
Attribute
: targetValue [1]: valueType
The target value that is used to set the outcome when a match is found.
There is one built-in outcome variable, completionStatus, that is declared implicitly and must not appear in an outcomeDeclaration.
Delivery Engines must maintain the value of the built-in outcome variable completionStatus, a single identifier. It starts with the reserved value "not_attempted". At the start of the first attempt it changes to the reserved value "unknown". It remains with this value for the duration of the item session unless set to a different value by a setOutcomeValue rule in responseProcessing. There are four permitted values: completed, incomplete, not_attempted, and unknown. Any one of these values may be set during response processing, for definitions of the meanings see [CMI]. If an Adaptive Item sets completionStatus to completed then the session must be placed into the closed state, however an item session is not required to wait for the completed signal before terminating, it may terminate in response to a direct request from the candidate, through running out of time or through some other exceptional circumstance. Adaptive Items must maintain a suitable value and should set completionStatus to "completed" to indicate when the cycle of interaction, response processing, and feedback must stop. Non-adaptive Items are not required to set a value for completionStatus, but they may do so. Delivery Engines are encouraged to use the value of completionStatus when communicating using [CMI]. See the accompanying integration guide for more details.
Class
: itemBody (bodyElement)
assessmentItemContains
: block [*]
The item body contains the text, graphics, media objects, and interactions that describe the item's content and information about how it is structured. The body is presented by combining it with stylesheet information, either explicitly or implicitly using the default style rules of the delivery or authoring system.
The body must be presented to the candidate when the associated item session is in the interacting state. In this state, the candidate must be able to interact with each of the visible interactions and therefore set or update the values of the associated response variables. The body may be presented to the candidate when the item session is in the closed or review state. In these states, although the candidate's responses should be visible, the interactions must be disabled so as to prevent the candidate from setting or updating the values of the associated response variables. Finally, the body may be presented to the candidate in the solution state, in which case the correct values of the response variables must be visible and the associated interactions disabled.
The content model employed by this specification uses many concepts taken directly from [XHTML]. In effect, this part of the specification defines a profile of XHTML. Only some of the elements defined in XHTML are allowable in an assessmentItem and of those that are, some have additional constraints placed on their attributes. Only those elements from XHTML that are explicitly defined within this specification can be used. See XHTML Elements for details. Finally, this specification defines some new elements which are used to represent the interactions and to control the display of Integrated Feedback and content restricted to one or more of the defined content views.
atomicBlock, atomicInline,
caption,
choice,
col,
colgroup,
div,
dl,
dlElement,
hr,
interaction,
itemBody,
li,
object,
ol,
printedVariable,
prompt,
simpleBlock,
simpleInline,
table,
tableCell,
tbody,
templateElement,
tfoot,
thead,
tr,
ulThe root class of all content objects in the item content model is the bodyElement. It defines a number of attributes that are common to all elements of the content model.
Attribute
: id [0..1]: identifier
The id of a body element must be unique within the item.
Attribute
: class [*]: styleclass
Classes can be assigned to individual body elements. Multiple class
names can be given. These class names identify the element as being a
member of the listed classes. Membership of a class can be used by
authoring systems to distinguish between content objects that are not
differentiated by this specification. Typically, this information is
used to apply different formatting based on definitions in an
associated stylesheet.
Attribute
: lang [0..1]: language
The main language of the element. This attribute is optional and will
usually be inherited from the enclosing element.
Attribute
: label [0..1]: string256
The label attribute provides authoring systems with a mechanism for
labeling elements of the content model with application specific data.
If an item uses labels then values for the associated toolName and toolVersion attributes must
also be provided.
flow, paramobjectElements that can appear within an object.
inlineInteraction, inlineStaticsimpleInline, dt,
caption,
atomicBlockElements that behave as spans of text, such as the contents of paragraphs.
blockInteraction, blockStatic,
customInteraction,
positionObjectStageitemBody, simpleBlockElements that provide structure to the text, such as paragraphs, tables etc. Most elements are either inline or block elements.
Abstract
class : flow (objectFlow)
blockInteraction, customInteraction,
flowStatic,
include,
inlineInteractiontableCell, div,
dd,
liElements that can appear inside list items, table cells, etc. which includes block-type and inline-type elements.
Attribute
: base [0..1]: uri
An optional URI used to change the base for resolving relative URI for
the scope of this object. Particular care needs to be taken when
resolving relative URI included as part of an Item
Fragment. See Item and
Test Fragments for more information.
Abstract
class : inlineStatic (inline)
atomicInline, gap,
hottext,
math,
object,
printedVariable,
simpleInline,
templateInline,
textRunhottext, prompt,
templateInlineA sub-class of inline that excludes interactions.
Abstract
class : blockStatic (block)
atomicBlock, div,
dl,
hr,
math,
ol,
simpleBlock,
table,
templateBlock,
ultemplateBlock, gapMatchInteraction,
hottextInteractionA sub-class of block that excludes interactions.
Abstract
class : flowStatic (flow)
atomicBlock, atomicInline,
div,
dl,
hottext,
hr,
math,
object,
ol,
printedVariable,
simpleBlock,
simpleInline,
table,
templateBlock,
templateInline,
textRun,
ulsimpleAssociableChoice, testFeedback,
modalFeedback,
simpleChoiceA sub-class of flow that excludes interactions.
The following classes define a small number of common element types used by XHTML.
Abstract
class : simpleBlock (blockStatic,
bodyElement,
flowStatic)
blockquote, feedbackBlock,
rubricBlockContains
: block [*]
A text run is simply a run of characters. Unlike all other elements in the content model it is not a sub-class of bodyElement. To assign attributes to a run of text you must use the span element instead.
The structural elements of the content model that are taken from [XHTML] are documented in groups according to their suggested classification in [XHTML_MOD]. Only those attributes listed here may be used (including attributes inherited from parent classes). By default, elements and attributes have the same interpretation and restrictions as the corresponding elements and attributes in [XHTML].
Although pre inherits from atomicBlock it must not contain, either directly or indirectly, any of the following objects: img, object, big, small, sub, sup.
Contains
: flow [*]
Class
: object (bodyElement, flowStatic,
inlineStatic)
positionObjectStage, graphicInteraction,
positionObjectInteraction,
mediaInteraction,
drawingInteraction,
gapImgContains
: objectFlow [*]
Attribute
: data [1]: string
The data attribute provides a URI for locating the data associated with
the object.
Attribute
: type [1]: mimeType
Attribute
: name [1]: string
The name of the parameter, as interpreted by the object.
Attribute
: value [1]: string
The value to pass to the object for the named parameter. This value is
subject to template variable expansion. If the value is the name of a
template variable that was declared with the paramVariable
set to true then the template variable's value
is passed to the object as the value for the given parameter.
When expanding a template variable as a parameter value, types other than identifiers, strings and uris must be converted to strings. Numeric types are converted to strings using the "%i" or "%G" formats as appropriate (see printedVariable for a discussion of numeric formatting). Values of base-type boolean are expanded to one of the strings "true" or "false". Values of base-type point are expanded to two space-separated integers in the order horizontal coordinate, vertical coordinate, using "%i" format. Values of base-type pair and directedPair are converted to a string consisting of the two identifiers, space separated. Values of base-type duration are converted using "%G" format. Values of base-type file cannot be used in parameter expansion.
If the valuetype is REF the template variable must be of base-type uri.
Attribute
: valuetype [1]: paramType
= DATA
This specification supports the use of DATA and REF
but not OBJECT.
Attribute
: type [0..1]: mimeType
Used to provide a type for values valuetype
REF.
tableContains
: inline [*]
Class
: colgroup (bodyElement)
tableAttribute
: span [0..1]: integer
= 1
Contains
: col [*]
Attribute
: summary [0..1]: string
Contains
: caption [0..1]
Contains
: col [*]
If a table directly contains a col then it must
not contain any colgroup
elements.
Contains
: colgroup [*]
If a table contains a colgroup it must not directly
contain any col
elements.
Contains
: thead [0..1]
Contains
: tfoot [0..1]
Contains
: tbody [1..*]
In XHTML, table cells are represented by either th or td and these share the following attributes and content model:
Attribute
: headers [*]: identifier
Attribute
: scope [0..1]: tableCellScope
Attribute
: abbr [0..1]: string
Attribute
: axis [0..1]: string
Attribute
: rowspan [0..1]: integer
Attribute
: colspan [0..1]: integer
Contains
: flow [*]
tableContains
: tr [1..*]
tableContains
: tr [1..*]