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" /> </xsl:apply-templates> 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. Thanks. Don Bruey Lead Software Developer Creative Solutions mailto:dbruey@xxxxxxxxxxxxxxxxxxxxx XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Question about generation of , Daniel Veillard | Thread | Re: [xsl] Reading XSLT results into, David Carlisle |
[xsl] Question about generation of , Daniel Veillard | Date | Re: [xsl] Images and XSL FO, Sebastian Rahtz |
Month |