[Announce] XQilla version 1.1.0 released

[Andrew Welch]

On 9/4/07, John Snelson <http://x-query.com/mailman/listinfo/talk> wrote:
> > 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.

Nice!  I'm sure I could come with a more a challenging example though...

> > 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.

The point I was trying to make was that XQuery + XML DB should be able
to select nodes far faster than XSLT + REST API, so the ideal
combination is XSLT + XQuery extension function.

I was wondering though if XQuery is even needed - if there was an XSLT
extension function that took three arguments:

xmldb($db-uri, $collection, $xpath)

and returned a sequence then that would do the job...

Basically XSLT 2.0 gives me all that I need now - I just need a way to
retrieve nodes from GBs of XML.

I'm wonder if its feasible for an XSLT processor to implement the
XMLDB scheme, and whether that would be enough?

-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/