[
Lists Home |
Date Index |
Thread Index
]
> It seems odd to me that I've never seen an article comparing
> actual XSLT and
> XQuery code for say moderately complex operations.
Apart from my Knight's Tour, which Jonathan cited (and which is a very
untypical application), I thought I'd try a very simple transformation that
I had to do recently. The task is to remove those parts of a document rooted
at an element having the attribute secret="yes". This is bog-standard XSLT
and doesn't need any 2.0 features:
<xsl:template match="*">
<xsl:copy>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
<xsl:template match="*[@secret='yes']"/>
7 lines, of which 6 are copy-and-paste from many other stylesheets that
you've written before. (Add two lines if you will for the header and
footer).
Here's an attempt at an XQuery solution:
declare function m:copy($e as element()) as element()? {
if ($e/@secret = 'yes')
then ()
else element {node-name($e)} {
$e/@*,
for $n in $e/node() return
if $n instance of element()
then m:copy($n)
else $n
}
}
document{
m:copy(doc('input.xml')/*)
}
14 lines of code (twice as much), and less scope for reuse. No great
difference in the conceptual difficulty - both require an understanding of
recursion - but I think XSLT emerges here as the winner. (And remember this
is only XSLT 1.0).
But in fact there's a bigger issue - the XQuery code is wrong. It loses the
namespaces from the source document. Perhaps I'm missing something, but I
can't see any way to solve this. XQuery may be computationally complete, but
it's not actually closed over the data model - there is no way of generating
a namespace dynamically. As far as I can see at the moment, that's a
stopper, and this exercise has to be coded in XSLT.
Of course, I'm sure there are other problems where XQuery has the edge.
Michael Kay
http://www.saxonica.com/
|
