Re: [xsl] XPath proximity position in predicates

[David Landwehr <david.landwehr@xxxxxxxxxxxx>]

Hi Michael

I have no practical use case.

I have an XPath (1.0) implementation as part of my open source XForms 
project and I'm doing some optimizations on it at the moment. I was 
looking at when I could simply skip evaluating a path expr containing a 
predicate. In the static analyze I got a result where the predicate 
didn't evaluate to a integer and therefore failed to locate a node. 
Since the predicate contained a static expression (e.g. just some 
calculations that should be folded during compilation of the expression) 
I was a little surprised. Now the good thing about this is that I can 
optimize this the other way around and say that I don't have to evaluate 
the path expr if a predicate contains a number which isn't an integer.

Best regards,
David

Michael Kay wrote:
> > Reading XPath 1.0 it states that a predicate evaluating to a 
> > number will return true if equal to the proximity position of 
> > the current node. I was wondering if there is a reason the 
> > evaluated number isn't rounded by the XPath engine?
> >     
>
> My guess on this is that no-one thought about this case before the 1.0 spec
> was published - remember that it didn't have anything like the extended
> review period that the current specs are going through. However, I think it
> rarely causes a problem in practice. Anyone computing the position using
> something other than simple addition or subtraction, for example to
> implement a binary-chop search, should really be thinking about the rounding
> strategy to use rather than relying on any default rounding algorithm; and
> simple addition and subtraction using small integer values doesn't lead to
> rounding errors.
>
> If there's a practical use case where problems arise, I'd be interested to
> hear of it.
>
> Michael Kay
> http://www.saxonica.com/