[
Lists Home |
Date Index |
Thread Index
]
Here is my 2 cents opinion.
I think we should stop comparing XSLT and XQuery. There
is no winner among the two. They are computationally equivalent,
and they are fortunately compatible with each other.
They each use different programming styles, and each one is
better under certain circumstances. I personally prefer XQuery
when the data has an expected shape, and I prefer XSLT while
dealing with unpredictable data shapes.
I think XQuery is easier to optimize, simply because it is simpler
to do dataflow analysis (i.e. to know what operations are applied to
each data items, and what data items are given as input to each
operation), and that's the bread and butter of any compiler/optimizer
technique. But that doesn't mean that it is not possible in XSLT.
My ideal situation would be to be able to mix and match, i.e
import a XSLT program in an Xquery and call it as a function, and call
an XQuery function from XSLT.
I don't think it is healthy to put XSLT and XQuery in competition.
Best regards,
Dana
On Dec 2, 2004, at 3:41 PM, Michael Kay wrote:
>> 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/
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
|
