It is probably best to store both the questions and answers in the same doc, and then break out the questions and answers using different filters. Here is an example approach:
<?xml version="1.0"?>
<data>
<question id="1">
<qtext>What does KB stand for?</qtext>
<choices>
<choice>Kilo Bits</choice>
<choice>Key Board</choice>
<choice>Kilo Bytes</choice>
<choice>None</choice>
</choices>
<answer>2</answer>
<answer>3</answer>
</question>
<question id="2">
<qtext>CPU stands for</qtext>
<choices>
<choice>Central Processing Unit</choice>
<choice>Central Power Unit</choice>
<choice>Core Processing Unit</choice>
<choice>Core Power Unit</choice>
</choices>
<answer>1</answer>
<answer>4</answer>
</question>
<question id="3">
<qtext>1 KB equals</qtext>
<choices>
<choice>1000 Bytes</choice>
<choice>1024 Bytes</choice>
<choice>1000 Bits</choice>
<choice>1024 Bits</choice>
<choice>Nothing</choice>
</choices>
<answer>2</answer>
<answer>1</answer>
</question>
</data>
Then use any XML parser, XML::Parser, XML::Twig, etc. to extract the <choices> and <answer> parts separately. Yould could also probably do this using XSLT, too, if you wanted to reamin XML pure. But I would go for the perl-based solutions first.
| [reply]
[d/l] |
I've had great luck with Andy Wardley's Template Toolkit (cpan). It is a very powerful general purpose templating system. Futhermore, since the template gets processed into a scalar you can then embed the oputput into another template and so on. I believe this will provide you with the dynamism that you are looking for.
Good Luck!
| [reply] |
I yet haven't had time to study the following document... (but it might be what you are looking for):
Combine disparate data systems with XML
by Phillip Perkins(published by Builder AU Web Development Zone - Fri, 19 Nov 2004 12:17:28 +1100)
Note: I had to copy all the article because I couldn't find it at the site. (Something that has happened in several occasions.)
One of the coolest things about XML is that it's a
platform-independent method of representing data.
What's even neater is that if you need to combine
two or more data sources into one logical data source,
you can do it easily with XML.
An example I encounter frequently is combining DB2 data
and Microsoft SQL data.
Your new application will gather data and store support
data on SQL 2000.
However, any user-specific data (such as human resource data)
is stored in DB2.
This can cause a problem if you need to collect information
from both data sources. But, with XML, all you need to do
is create identical XML structures from both data sources
and combine them.
This is particularly helpful if you're going to run
this information through an XSLT transformation.
Though you need to find the perl equivalence, these lines
are a good starting point (XML, XSLT, DBI, etc.).
This author has a lot more of the kind to read at that site
(Building XML from several forms, etc.).
| [reply]
[d/l]
[select] |
In addition to the Perl templating systems others have mentioned, if the data to be merged into the XML template is itself in an XML document then you should definitely consider the standard XML templating language XSLT.
You can process XSLT using XML::LibXSLT or XML::XSLT but if the purpose of the exercise is to generate a display in a modern web browser then this is unneccessary - you simply send the data XML to the browser with a processing instruction telling the browser where to find the template (aka XSL stylesheet). | [reply] |
