[Announce] XQilla version 1.1.0 released

[Jonathan Robie]

John Snelson wrote:
> Andrew Welch wrote:
>> On 9/4/07, David Carlisle <http://x-query.com/mailman/listinfo/talk> 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
>>> it?
>>
>> 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
>> XSLT.
>
> 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.

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.

Jonathan