|
[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message] [Announce] XQilla version 1.1.0 releasedJohn Snelson john.snelson at oracle.comTue Sep 4 14:03:11 PDT 2007
Andrew Welch wrote: > On 9/4/07, John Snelson <http://x-query.com/mailman/listinfo/talk> wrote: >>> 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. Surely what you really want is an XSLT processor in the XML database? There's no reason why you need XQuery to access an XML database if it will let you send it XSLT directly, and return you the results. > 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... Right - that would be the other way to do it. If you want your XSLT to be executed by the database client, you can just make calls into the XML database from the XSLT. This approach would give less scope for the database to optimise the XSLT using it's indexes though. John
|
Purchase Stylus Studio Online Today!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|

![[Announce] XQilla version 1.1.0 released](/images/get_stylus.gif)




