[QTI] a stripped down assessmentTest?

[Steve Lay]

Deryl,

Interesting question, I've given a few views on a couple of the points 
you make below and made some suggestions.  Just my personal opinions 
though...

Deryl Seale wrote:
> I find the assessmentTest schema and packaging strategy to be fairly 
> cumbersome for a lot of the operations we're implementing in our 
> application, in particular the requirement of separating the items into 
> separate XML files and metadata into a separate manifest file.

QTI is designed to cover a fairly wide range of use cases with one 
interoperable format.  In particular, the choice of IMS content 
packaging allows the safe exchange of the media files that support 
assessment tests and items.  In your use case, which doesn't require the 
media files, it naturally appears cumbersome.

 From the point of view of the system exporting the content, a single 
format that supports a wide set of applications does make sense though.

> For example, we have a requirement to present an assessment in a machine 
> readable format to upload to a scanning and scoring platform, which 
> needs only to read in the questions to get their correct answers (in 
> this case, multiple choice). It's burdensome to require a client to 
> process an archive file, such as a ZIP or TAR file, then perform file 
> operations, and then process the XML contents one by one -- being able 
> to simply send a single XML file for a client to process would be much 
> simpler.

Assuming that the test was in QTI format at some point prior to delivery 
to candidates then the issue is really one of identifying when it is 
sensible to throw away the information you don't need anymore.  I don't 
think unzipping and performing the file operations will have a 
significant effect on the performance of a scanning engine, unless each 
candidate has had a uniquely generated test.  *Ideally* you'd simply use 
a library which helped you with this so there wouldn't even been much 
more code to write (several initiatives are happening in Java at the 
moment that might help if you are working in that language).

You could also write a pre-processor to simplify the solution for your 
scanning software if the cost of making changes to it is too high of 
course.  Depends on whether the scanner system has QTI support as a goal.

> Likewise, is there any way to embed the metadata in the test XML file, 
> as opposed to placing it in a separate manifest file?  If I want to 
> include this information for the above mentioned export function, it 
> would be nice to be able to embed in directly in the assessment XML -- 
> the metadata structure is in its own namespace, so I don't see why it 
> couldn't happily co-exist with the assessment XML.

Again, for some applications this makes sense, for others it would be 
problematic.

> In general, it seems like this export strategy makes things harder on 
> the client, and I can't see any see any benefit to benefit to breaking 
> up an assessment into a bunch of separate files.  Short of creating my 
> own XML structure -- and I reluctant to do that and become "proprietary" 
> -- I don't see any good way to make things simpler for consumers of QTI 
> data.  Any helpful advice?

There are lots of arguments for and against.  *One* of the advantages of 
this representation is that it allows a pool of items to be used to 
generate a large number of similar tests.  In other words, treating the 
items as a resource pool from which the tests are drawn.  (Yes, this is 
a real use case.)

Perhaps more importantly here though is the issue of your reluctance to 
become "proprietary".  If you have already managed the QTI import during 
the step that publishes the tests for distribution to candidates 
(presumably on paper in your case), then there is no reason why you 
shouldn't use that step to create an optimized data file for the scanner 
system.  (Indeed, if you were doing more than multi-choice this might be 
the only practicable way to communicate to the scanners where on the 
page the responses should be scanned from.)

But, *if* you go down this road I would strongly suggest *not* starting 
from scratch.  You could use something like SchemaProf to make a profile 
of QTI that supports your use case (it has a flexible definition of 
profile which would allow you to do what you want I think).  If you 
stick to the same data elements as QTI but just arrange them in a way 
that is optimized for your solution then adding QTI support in the 
future will be much easier.

Steve