[xquery-talk] [Announce] XQilla version 1.1.0 released
john.snelson at oracle.com
Tue Sep 4 17:29:03 PDT 2007
Jonathan Robie wrote:
> John Snelson wrote:
>> Andrew Welch wrote:
>>> On 9/4/07, David Carlisle <davidc at nag.co.uk> wrote:
>>>>> 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.
>>>> why does it have to be an extension function? XQuey and XSLT difer
>>>> mainly in surface syntax so if the XQuery engine can be hooked up to a
>>>> DB rather than an in memory tree, it's surely not impossible for the
>>>> Xpath that's embedded in XSLT to access a database in teh same way is
>>> I was thinking about that (perhaps implementing Saxon's NodeInfo to
>>> work on the XQuery data model) but I don't think its needed... (and I
>>> may be talking nonsense there)
>>> All that's needed is a high level way to select from the db - thats
>>> it. Whether it's through passing an XQuery to an extension function
>>> that returns each tuple as an item in a sequence, or using a REST
>>> interface that returns each tuple as element in a document, once you
>>> have that then the rest of the processing can be done using standard
>> I think the point here is that it will never be as fast in a stand
>> alone XSLT processor as in one which can use the database's indexes
>> and statistics to optimise the stylesheet.
>> Since the XQuery data model is the same as the XSLT 2.0 data model,
>> this all shouldn't be that hard.
> For evaluating the path expressions, I agree with you. In general,
> though, I don't think that XSLT templates that are triggered based on
> recursive descent in document order is as easily optimized as XQuery
> FLWOR expressions.
I agree, of course - it's not as easily optimized, but it's still
possible to some extent or other.
John Snelson, Oracle Corporation
Berkeley DB XML: http://www.oracle.com/database/berkeley-db/xml
More information about the talk