This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Reading XSLT results into a program (long)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: RE: [xsl] Reading XSLT results into a program (long)
- From: Wendell Piez <wapiez at mulberrytech dot com>
- Date: Fri, 19 Jan 2001 15:06:52 +0000
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Don,
I'm no db guy, but it seems to me that David's on when he suggests that XML
output would be more useful, and just as easy, as CSV, at least if you were
having to run a parser over the stuff again. It's true that you face an XML
design question at that point, which seems like an extra step. But from
another point of view, the question of the design of the output has always
been there, just not on the surface.
Assuming that unless there's a reason you want it another way, the design
of the output might simply reflect the design of the input, your default
might well be to base your stylesheets on the identity transform. It's not
hard to take the recursive one-node-at-a-time identity transform (it's
given in the XSLT Rec, 7.5), and add a template with a select expression
(and maybe a sort instruction) for your query. That makes a two-template
stylesheet to change between applications.
That is, it may be a feature, not a bug, that there isn't a single way or
even a "best" way: but there are still ways that are pretty easy.
Heck, here's an example, two templates that select out all the 'reader'
elements from arbitrary input XML, sorted alphabetically by their
'username' attributes:
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="/">
<result>
<xsl:apply-templates select="//reader">
<xsl:sort select="@username">
</xsl:apply-templates>
</result>
</xsl:template>
It's pretty easy to spin off that; and the model is easy to extend if you
want to suppress stuff, further rearrange, etc.
Regards,
Wendell
At 12:11 PM 1/19/01 -0500, you wrote:
>The XSL-ness of the question is in the output of the transformation - I want
>to use XSLT to filter/sort my XML data. It's not really an XML question per
>se. I would like to have a "neat" way of always transforming into some
>format of data, like SQL gives you when it produces a resultset for you.
>
>I think the answer is that there isn't a way - that's what I was looking
>for, hoping not to have missed some obvious or clever way to handle XSLT
>output. Tools such as XSLT have to be considered when making the choice of
>relational DB vs. XML storage and I am asking the question in that respect.
>Thanks to all who responded.
>
>Don
======================================================================
Wendell Piez mailto:wapiez@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list