CETIS-QTI-SIG:

Here are some comments on the points raised by Graham last month -
hopefully these comments will help to provoke discussion in the run up to
the Presentation-themed meeting of the SIG in Leeds.

By the way, I've snipped most of Graham's original from this post to make
this reply easier to read but I hope I've left enough in to remind people
of his message!

At 12:30 +0100 12/4/01, Graham Smith wrote:
>These comments are a result of difficulties experienced when writing
>experimental software to use the IMS specs in  a new question and
>test system. Members of the SIG may be interested to see examples of
>the way this prototype handles IMS XML by comparing the HTML produced with
>the source XML.
>The link is:
>
>http://www.odltest.leeds.ac.uk/IMSindex.htm

>1. Placing the <material> element.

Firstly, I agree that the specification does have a weakness in the
variability of material placement.  Systems designed to import QTI data
were always likely to show up these problems.

The current specification says little or nothing about the function of
material appearing in the various positions allowed.  During the
introduction of the flowed-material concept the working group discovered
considerable differences in the existing interpretations.  Section 4 of the
information model was updated to discuss flow but hasn't gone as far as to
discuss the rendering of material other than images - a section which seems
hard to interpret outside the use of material in render_hotspot.  Because
material has been liberally applied to the DTD there are many more
anomolies.  The use of material within other render_hotspot mentioned
above, for example, is quite alarming.

One comment I would make on Graham's proposal is about the interpretation
of the response_lid.  After much deliberation we decided that response_lid
(and it's friends) should not have any flow (and hence layout) semantics at
all, mainly because there are situations where it is clearly not wanted.
(For example, a render_extension that pops up a list of words to choose
from in a multi-choice version of fill in the blanks.)

As a result, we couldn't (as a matter of policy) distinguish material
inside response_lid from material outside.  material was retained in the
gap for backwards compatibility but removed from QTI Lite because we didn't
have a QTI Lite 1.0 (so we didn't need to be compatible).  I don't remember
exactly why this got altered but my interest in QTI Lite is limited so I
may not have realised the importance of that change.

The intention was to use flow as the hooks upon which all layout semantics
could be attached.  If an item does not use flow you are free to do what
you want during rendering (and so is anybody you interoperate with) so you
can guess at the meaning of material given it's location if you want.
However, if an item uses flow then you should honour it.

The real problem here is that you are making a distinction between material
of a general nature and material of the 'stem'.  QTI does not have the
concept of 'stem'.  What would be useful to know is what other logical
divisions of presentation there might be.

On the wider matter of how to interpret material when you find it - if we
work through this at the forthcoming SIG meeting in Leeds and wrote up the
discussion the resulting document would help others implementing QTI I'm
sure.

The example your mail refered to was a case of common material shared by a
number of questions.  It seems to me that this is really what the section
structure should be used for though at present material is not allowed at
that level.  One of the things people really want to do is to use
forthcoming selection rules to choose a subset of items in a section that
all share some common material (such as a reading passage).  Common rubric
is allowed so it seems odd not to allow common material.

I'll raise your ideas at the meeting here in Boston (if Andy doesn't do it
first).

>2. Presentation. (This takes up the point in the paper which Karen
>presented to the recent meeting. I appreciate that 'presentation' did
>not necessarily mean the presentation element. The question of the placement
>of <material> is also relevant to Karen's point.)

Hopefully line breaks can now be specified by labelling the material as
being white-space significant (which includes the location of line breaks).
Note that this doesn't imply a fixed width font - just white-space
preservation.

Emphasized text can take advantage of the new text tag matemtext.

>I agree with Karen there is insufficient mark-up allowed in the spec
>for the text, which is to be included as PCData in the DTD, and
>with her point about the need to specify line breaks and
>emphasised text. I have had to solve this problem in a practical
>application needed now.  Since the tests I am concerned with are
>to be distributed over the Web, and the xml is converted to html, I
>have solved this and other similar problems by including standard
>html mark up in Cdata sections, which the dtd will accept if
>contained inside PCdata sections. ( I note that there is a least one example
>among those on the IMS site whch does this (mchc_ir_102.xml), and my
>colleaguie Jon Maber has also, quite independently, adopted this approach)

The inclusion of HTML-like tags is an interesting one.  On the one hand
most people assumed that "text/html" on an inline mattext meant that you
could put HTML tags in willy nilly.  To some extent you can then see QTI as
a sort of template language based on HTML in which the QTI markup expands
to various bits of HTML making a complete document (just like your
favourite server-side scripting tool but turned inside out).  Whatever the
merits (or otherwise) of this approach there is a strong feeling that the
specification should not be tied to HTML (or any other such language) so
introducing other HTML like concepts (like <BR>, <PRE> or whatever your
favourite tag is) was out of the question.

On the other hand - if we say that "text/html" does not mean a complete
HTML document then we get in a mess when people leave dangling tags (such
as unclosed tables) because we can't judge their intention.  So your method
gets round the problem but, as you suggest, it is not helping
interoperability because you'll have agree what all that stuff means
outside QTI.

>I appreciate that the IMS mark-up is designed to be rendering-
>engine independent, and so markup which is html specific could be
>frowned upon.  However, if text mark-up tags are needed, why not use the
>widely- accepted standard html mark-up here instead of inventing new tags?

In the UK HE sector this sounds so reasonable.  But once you've met a few
people with item banks stacked full of RTF based content you hear the same
thing but with "RTF" substituted for HTML.  Indeed, some people are
doubtless using QTI in just this way but with RTF tags.

>this point). Steve Lay made a contribution to the IMS international
>forum which suggests he may have thought on similar lines,
>although I did not see earlier relevant comments. "Flow and QTlite,
>a problem", 4th Feb 2001)

Indeed, if it came to a vote I would have gone for HTML too - warts and
all.  My feeling is that you can document the syntax (in the DTD/schema)
but you don't have to explain the semantics.  The class attribute of flow
is supposed to allow the block-level and grouping elements of HTML to be
identified when desired (tables are still on the table, so to speak).
Given the vocabulary approach it would be reasonable to provide an
HTML-based vocab for the class of flow right now.

Inline text currently comes in only two flavours: regular and 'em'.  There
seems no reason not to encourage a similar 'class' approach here too.  The
advantage of flows is that they are simple to document in QTI, could be
used to apply rtf semantics if preferred and support proper hierarchies of
material (an issue fudged by HTML).  The disadvantage is the lack of
validity checking:

<flow class='table'><flow class="p"></flow></flow>

What does 'p' mean in HTML 'table'?

That's probably enough for one message.

Steve Lay