[xquery-talk] [Announce] XQilla version 1.1.0 released
andrew.j.welch at gmail.com
Tue Sep 4 13:49:18 PDT 2007
On 9/4/07, John Snelson <john.snelson at oracle.com> 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?
More information about the talk