[QTI] Questions about extendedTextInteraction

Daniel Cassidy ims-qti at danielcassidy.me.uk
Tue Nov 11 16:21:25 GMT 2008


Hi List,

Having read the QTI 2.0 spec, I'm quite unclear on how
extendedTextInteraction is intended to behave in some circumstances,
or what precisely is the intended meaning of some of its attributes.

1) The expectedLines attribute is not clearly specified, since no
   definition is given as to what constitutes a 'line':

    * It could simply refer to the expected number of linebreaks in
      the candidate's response. However, assuming line wrapping is
      in use, it is difficult for a delivery engine to use this
      information to size the response box since the height will
      depend on the length of the lines entered by the candidate
      as well as the number of lines.

    * It could refer to the expected number of lines of text taking
      line wrapping into account, but this is meaningless unless
      the length of a line is defined.

   Assuming both expectedLines and expectedLength are both
   specified, would it be reasonable to interpret an
   extendedTextInteraction as roughly equivalent to the following
   HTML element?

       <textarea rows="expectedLines"
           cols="ceil(expectedLength / expectedLines)"

   (where obviously one is expected to evaluate the values of the
   rows and cols attributes prior to delivery to a browser).

   What about in the case where expectedLines is specified but
   expectedLength is not? In this case I cannot determine any
   sensible way to interpret expectedLines.

2) If an extendedTextInteraction has multiple cardinality, how
   should it behave? Should it consist of multiple separate input
   boxes, or is it expected that the candidate's response into a
   single input box should be split up in some way?

3) The specification seems to fall short of allowing the test author
   to clearly specify their intentions when using the maxStrings
   attribute. That is, if the author specifies maxStrings="5", they
   could mean one of two things:

    * A correct answer consists of exactly five strings. A candidate
      entering less than five strings cannot expect to get full
      marks.

    * A correct answer consists of *up to* five strings. The
      candidate may be able to enter less than five strings and
      still receive full credit.

   These two cases are quite different, and require different
   cues to the candidate.

   In the first case, it might be best to always display five input
   boxes. In this case it is clear to the candidate that exactly
   five strings are expected.

   In the second case, if the delivery engine always displays five
   input boxes, the candidate could mistakenly believe that exactly
   five strings are expected even though this is not the case. In
   this case, it would be better to provide one input box, and
   provide an interface to allow the candidate to enter additional
   strings, up to a total of five.

   The second case could be even more problematic is the author
   specifies a large maximum (such as maxChoices="20"), and the
   delivery engine displays twenty input boxes where in fact an
   answer consisting of only two or three strings might be correct.

   Presumably if maxStrings is unspecified the delivery engine must
   always provide some interface to provide an additional response
   if the candidate wishes?

4) How do expectedLength and expectedLines apply to an
   extendedTextInteraction with multiple cardinality?

   For example, if expectedLength="20", does that mean that the
   total concatenated length of all strings is expected to be
   around 20 characters, or does it mean that the total length of
   each string individually is expected to be around 20 characters
   (so some multiple of 20 characters overall)?


Any advice is much appreciated.

Thanks,
Dan.



More information about the IMS-QTI mailing list