[xquery-talk] [Announce] XQilla version 1.1.0 released
jonathan.robie at redhat.com
Tue Sep 4 11:55:16 PDT 2007
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
XQuery was designed to take advantage of indexed stores in a way that
XSLT was not. XPath was also designed as a declarative language that
could be used for indexed storage.
More information about the talk