> The problem with using text in database fields is not that
> it is not portable but rather that it is constraining on
> the question designer because you must have a fixed number
> of answers to each MCQ.

Text has nothing to do with it. It's the way the data is stored that's
important. Martin Schranz indicated as much in his previous post.

All I'd say to extend Martin's response is to say that by using a relational
database any number of elements, text or any format you care to envisage,
can relate to a single entity, in the context of MCQs, a stem.

Where XML becomes important is in encoding these related elements into a
format that may or may not become a standard way of exchanging data.

In a related table there are a potentially unlimited number of branches that
relate to this stem. In Martin's case, where he has used database
relationships creatively to generate a huge number of stem <-> branches
combinations, you could envisage a class of capital cities, say, 100 cities
in your database, that you could use to generate a huge number of capital
city variant questions.

We use the same technique to manage extended matching questions. It's a very
powerful technique and allows you to effortlessly generate loads of
questions, all of equal validity, such that as an extreme example you could
delivery a unique question with the same stem to each student in a test
group.

Now in Martin's question database, and our extended matching database, the
data is stored a plain text. The usefulness of XML is when this data gets
encoded for transport across the web either to another MCQ system or in some
kind of resource discovery application.

Take this simple XML code snippet as an example.

I have a relational database containing 2 tables. One table contains the
stem, which when encoded to XML might be represented as:

<stem>What is the capital of France</stem>

My script will randomly allocate any number of optional branches including
one containing the correct answer thus:

<branch>London</branch>
<branch>Paris</branch>
<branch>Munich</branch>

The bottom line, the data is stored as ASCII text, the wrapping used for
either exchange or transformation to HTML is XML.

I hope than over the next day or so Martin and I will be able to show a real
application of a collaborative linkage of two very different database
technologies using XML to deliver MCQs to the user.

That is if I'm not tempting fate too much!

Cheers,

David.