[xsl] Reading XSLT results into a program (long)

Subject: [xsl] Reading XSLT results into a program (long)
From: Don Bruey <dbruey@xxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 19 Jan 2001 08:48:47 -0500
I have a question about XSLT output and how it's manipulated in a program.  

For any company that is thinking about using XML as a primary data storage
mechanism, it seems to me that the biggest issue (beyond data conversion or
format of the XML document) is the issue of how to read the XML data and act
on it.  Example:

I have database table named Customers.  I do a SQL on it:  

"SELECT * FROM Customers WHERE id <> 'don' ORDER BY id" 

This will "return" a recordset/resultset  in memory I can manipulate it. The
output from a Select statement is predictable, it will be in a
recordset/resultset format.

If I have that same data in an XML document like this:

...<customer><ID>123</ID><name>Vendor Name</name>...</customer>...

I can say 

<!-- didn't test this -->
<xsl:apply-templates select="//customer[ID != 'don']" >
  <xsl:sort select="ID" />

And this will apply templates for each of these elements.  The question here
is:  What is the output going to look like?  I can write templates to do a
lot of things - I can output simple CSV for each of the elements and parse
that within my program, I can use <xsl:copy or <xsl:copy-of to transform
this into another XML format, or to contain a subset of this XML document.
The point is that I can use many ways to represent the result of the
apply-templates call. Or I can use DOM or SAX from my program to read the
document and filter it, then sort the data after that. 

I recently wrote a project in XML/XSLT where I had several different XML
files. Some of them just had user settings and supporting data, and some
were the actual data to be reported.  The user settings were related to how
the user wants the data to be shown or organized.  When I read in the user
settings/supporting data (using DOM or XSLT via DOM), I found that I didn't
have an obvious way to store that information right off the bat.  If I were
to use SQL with a database, it would be obvious - the result is a
recordset/resultset.   When you transform XML, or even when you read XML
straight using DOM or SAX, you have to make an extra decision for how to
represent that data and manipulate it once you're done with your
transforming/reading operation.  It's true that these mechanisms exist for
the sole purpose of making it easy to read information from an XML document,
but you still have to put some thought into how they're stored for your
program.   I ended up using the DOM and XSLT to create CSV representations
of the user settings I had to read in, but then I had to parse that data
into structures and arrays with loops that look for commas.  

Seems like using XML as a primary data storage mechanism gives the developer
more work if the XSLT isn't just creating straight HTML or something like
that. It's true that you have to also create arrays/structures for resultset
data - but you always have a well-defined starting point, the SQL statement
will generate a well-known representation of the data for you to handle.
Please correct me if I'm wrong here - there seems to be an unavoidable extra
decision and extra coding step if doing the same thing with XML/XSLT, as in
the example above. 

You might consider this an XML question - I think it is really an XSLT
question since my typical concern is filtering/sorting data when reading XML
and then doing something with the results, like with SQL.  The answer to
what I can do with XSLT vs. SQL has a direct bearing on the XML vs. database
question.  I have rarely needed to just read XML from start to finish.  I'm
looking for advice or confirmation about XSLT and ways of generating
"consistent" or standard output formats.  

Does anyone have thoughts on this that would contradict what I've concluded
above about storage or ease of manipulation of XML data?  Do you have a way
you always read data that always brings it in the same way using XSLT?   I'm
not saying my view on this is absolutely correct - honestly, I'd love to
have someone tell of a solution they've had to this issue.  I know that
XSLT/XML are good for what they're good for, and that there is no
one-size-fits-all storage mechanism, but it would be interesting to know how
other people handle routine reading and handling of XML data via XSLT.


Don Bruey
Lead Software Developer
Creative Solutions

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread