Re: Optimization and XPath (was RE: Why not reinvent the wheel?)

[Charles Reitzel <creitzel@mediaone.net>]

That's about how I understood it.  I also was under the impression that
folks are working out the rules for downward-only form of XPath for just
these reasons.  If a template/query contains up-and-over XPath expressions,
then a performance cost will be paid.  

My point was that XQuery has no advantage in optimizability.  Implementors
of either language will have to be aware of the same issues.  Thus the need
for XQuery/XSLT coordination on XPath you describe, Jonathan.  

Joe, I'm curious, what makes XQuery look more optimizable to you?  In
another message you mention the random access requirements of the template,
which is what we're talking about here.  It strikes me that XSLT and XQuery
implementations, alike, will have to analyze contained XPath and detect
up-and-over expressions.

take it easy,
Charles Reitzel


On Sat, 24 Feb 2001 Jonathan Robie wrote:
>Joe English wrote:
>
>>Jonathan Robie wrote:
>>
>>I wouldn't go that far either; the structure of 
>>XQuery does look to me like it's more amenable to 
>>optimization than XSLT.  But the '..' axis is
>>definitely problematic.
>
>[ !! SNIP !! ]
>
>>  In fact with lazy evaluation and a bit of care,
>>you can obtain good space usage almost for free
>> (see for example HaXML).
>
>Hmmm ... I asked myself why Joe English knows about
>HaXML, went to his web site, and realized that this
>is the Joe English who did Cost 
>(http://www.flightlab.com/cost/)
>
>>But with '..', an end-user can define all the other
>>XPath axes:
>>
>>         -- modulo typos and type errors...
>>         FUNCTION ancestor(ELEMENT $e) RETURNS LIST(ELEMENT)
>>         {
>>                 $e/.. UNION ancestor($e/..)
>>         }
>
>Well, yes.
>
>Now the question - if a user chooses to write
>recursive functions to do this sort of thing, 
>does that user have the right to expect that 
>we will optimize such queries well?