[xquery-talk] [Announce] XQilla version 1.1.0 released

[John Snelson]

Andrew Welch wrote:
> On 9/4/07, John Snelson <john.snelson at oracle.com> wrote:
>> Andrew Welch wrote:
>>> The key point here is that the XSLT has access to whole result set,
>>> not just each tuple, so that it can use its powerful grouping
>>> facilities over the whole set.  You use XQuery to construct the result
>>> set, and XSLT to process it.
>> You'll be looking forward to XQuery 1.1 then - with it's promised
>> grouping facilities ;-).
> 
> If it follows XSLT then 1.1 will be dropped in favour of 2.0... and
> it'll be another 7 years in the making :)
> 
> There are other benefits of XSLT over XQuery though - if your target
> output is markup then its much nicer to generate that markup in XSLT
> than XQuery, and XSLT's recursive processing model is better suited to
> document centric XML - for example "copy the entire document except
> <para>s with no <subpara>s"

How about this XQuery Update:

copy $doc := doc("myDocument")
modify delete nodes $doc//para[not(.//subpara)]
return $doc

That's exactly the kind of use case that I expect to be more intuitive 
to do in XQuery Update.

However, I do agree that XSLT is much nicer for expressing certain use 
cases - like creating presentation markup from declarative markup, for 
instance.

> XQuery [is | should be] much better for selecting nodes, so XSLT with
> embedded XQuery seems a natural combination for XML dbs that store
> document centric XML with a target output of (X)HTML.

I'm not sure I agree. XSLT 2.0 uses XPath 2.0, and there isn't a lot 
that XQuery has that XPath 2.0 doesn't have. The only truly substantive 
things are "order by" and node construction - but XSLT can already do 
both of them.

John