At a recent IMS meeting I again mentioned that transforming QTI v2 into HTML shouldn't be too difficult and that I'd already made a start on this project many years ago. I even mentioned it in an earlier blog post: Semantic Markup in HTML. To my shame, I got a comment on that post which called my bluff and I haven't posted my work - until now! I won't bore you with the excuses, day job, etc. I should also warn you that these files are in no way complete. However, they do solve most of the hard problems in my opinion and could be built out to cover the rest of the interaction types fairly easily.
If you want to sing along with this blog post you should look at the files in the following directory of the QTI migration source repository: https://code.google.com/p/qtimigration/source/browse/#svn%2Ftrunk%2Fqti2html. In there you'll find a collection of XSL files.
qti2html.xsl
The goal of this project was to see how easy it would be to transform QTI version 2 files into HTML 5 in such a way that the HTML 5 was an alternative representation of the complete QTI information model. The goal was not to create a rendering which would work in an assessment delivery engine but to create a rendering that would store all the information about an item and render it in a sensible way, perhaps in a way suitable for a reviewer to view. I was partly inspired by a comment from Dick Bacon, of SToMP fame. He said it would be nice to see everything from the question all in one go, including feedback that is initially hidden and so on. It sort of gave me the idea to do the XSL this way.
Let's see what this stylesheet does to the most basic QTI v2 example, here's the command I ran on my Mac:
xsltproc qti2html.xsl choice.xml > choice.xhtml
And here's how the resulting file looks in Firefox:
The first thing you'll notice is that there is no HTML form in sight. You can't interact with this page, it is static text. But remember the goal of this stylesheet is to represent the QTI information completely. Let's look at the generated HTML source:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:qti="http://www.imsglobal.org/xsd/imsqti_v2p1">
<head>
<title>Unattended Luggage</title>
<meta name="qti.identifier" content="choice"/>
<meta name="qti.adaptive" content="false"/>
<meta name="qti.timeDependent" content="false"/>
<style type="text/css">
<!-- removed for brevity -->
</style>
</head>
To start with, the head element contains some useful meta tags with names starting "qti.", this allows us to capture basic information that would normally be in the root element of the item.
<body>
<h2>Unattended Luggage</h2>
<div class="qti-itemBody">
<p>Look at the text in the picture.</p>
<p>
<img src="images/sign.png" alt="NEVER LEAVE LUGGAGE UNATTENDED"/>
</p>
<div class="qti-choiceInteraction" id="RESPONSE" data-baseType="identifier"
data-cardinality="single" data-shuffle="false" data-maxChoices="1">
<p class="qti-prompt">What does it say?</p>
<ul class="qti-choiceInteraction">
<li class="qti-simpleChoice" data-identifier="ChoiceA" data-correct="true">You
must stay with your luggage at all times.</li>
<li class="qti-simpleChoice" data-identifier="ChoiceB">Do not let someone else
look after your luggage.</li>
<li class="qti-simpleChoice" data-identifier="ChoiceC">Remember your luggage
when you leave.</li>
</ul>
</div>
</div>
I've abbreviated the body here but you'll see that the item body maps in to a div with a appropriate class name (this time prefixed with qti- to make styling easier). The HTML copies across pretty much unchanged but the interesting part is the div with a class of "qti-choiceInteraction". Here we've mapped the choiceInteraction in the original XML into a div and used HTML5 style data attributes to add information about the behaviour. Cardinality, etc. In essence, this div performs the role of both interaction and response variable declaration.
I chose to map the choices themselves on to an unordered list in HTML, again, using HTML5 data- attributes to provide the additional information required by QTI.
html2qti.xsl
So can this format be converted back to QTI v2? Yes it can. The purpose of this stylesheet is to take the XHTML5 representation created by the previous stylesheet and turn it back in to valid QTIv2. This gives us the power to work in either representation. If we want to edit the HTML we can!
xsltproc html2qti.xsl choice.xhmtl > choice-new.xml
The output file is not identical to the input file, there are some changes to comments, white space and the order in which attributes are expressed but it is valid QTI v2 and is the same in every important respect.
qti.xsl
Once we have an XHTML5 representation of the item it seems like it should be easy to make something more interactive. A pure HTML/JS delivery engine for QTIv2 is an attractive proposition, especially if you can use an XSL transform to get there from the original QTI file. One of the main objections to QTI I used to hear from the SCORM crowd back in the early days was that there was no player for QTI files that were put in SCORM packages. But given that most modern browsers can do XSL this objection could just disappear, at least for formative quizzes where you don't mind handing out the scoring rules embedded in the HTML. You could even tie up such an engine with calls to the SCORM API to report back scores.
Given this background, the qti.xsl file takes a first step to transforming the XHTML5 file produced with the first XSL into something that is more like an interactive question.
xsltproc qti.xsl choice.xhtml > choice_tryout.xhtml
This is what the output looks like in Firefox:
This page is interactive, if you change your choice and click OK it re-scores the question. Note that I currently have a score of 1 as I have the correct choice selected.
Future Work
These XSL files will handle some of the other variants of multi-choice, including multi-response (yes, even when interacting) but are in no way a complete method of using XSL to transform QTI. For me, the only compelling argument for using XSL is if you want to embed it in a package to force the client to do the transformation or if you are using one of those cocoon like tools that uses XSL pipelines at runtime. Realistically, writing XSL is a pig and so much time has elapsed since I wrote it that it would take an hour or two to familiarise myself with it again if I wanted to make changes.
But the key idea is the transforms enabled by the first two, which present an alternative binding for the QTI information model.
