Re: are multiple predicates same as boolean and

I have seen that the large number of predicates mean that you are
doing a hardwork in getting what you want from the xml.
It  is unavoidable in cases where the XML is pretty much unchangeable
because of the business of the company or because your XML source
comes from a third party. But if you are designing a system from the
scratch, with the design of XML , then a lot of thought on the
relational model of the business with an inclination to what the
Output would look like or is catering, will help create smarter , and
high performance stylesheet, coupled with the good features of the
XSLT2  ( potentially with less predicates )


On Fri, Nov 21, 2008 at 3:06 PM, Mukul Gandhi <gandhi.mukul@xxxxxxxxx> wrote:
> Thanks, David for further thoughts .. this makes me better at this.
>
> I have a related question ...
>
> for real world XSLT/XPath programs, upto how many predicates can we
> typically see?
>
> I haven't seen programs using 3, 4 or more predicates.
>
> X[..][..][..][..]
>
> I have used one or two predicates upto now.
>
> are excessively large number or predicates really useful? (the syntax
> allows that ...)
>
> I think perhaps, for complex 'and' conditions, using multiple
> predicates are useful ...
>
> On Fri, Nov 21, 2008 at 8:11 PM, David Carlisle <davidc@xxxxxxxxx> wrote:
>>
>>
>>> If X[@a='hi'] matches a node, then that node will become the context
>>> node when evaluating [@b='hi..']
>>
>> as Andrew just said [] the context node doesn't change, so
>>
>>> X[P][Q] is equivalent to X[P and Q] if and only if Q does not depend on
>>> the context node at all.
>>
>> isnt't true, howver
>>
>> context position (position() ) and size (last()) do change. so basically
>> repeated filters are equivalent to and unless any of them depend on
>> position() or last(), including the speical case of [integer] being
>> equivalent to  [position()=integer]
>> this last case is what makes it tricky to do a static rewite of this
>> unless you are a real XSLT engine that really know what is happening.
>> If you have
>> X[... foo ..][... bar ...]
>> you can only rewrite that to
>>
>> X[(... foo ..) and (... bar ...)]
>> if you know that neither expression will evaluate to a number at run
>> time. You probably don't know that unless you are the XSLt engine,
>> except in special cases.
>>
>> David
>
>
> --
> Regards,
> Mukul Gandhi
>
>



-- 
Vasu Chakkera
Numerical Algorithms Group Ltd.
Oxford
www.vasucv.com