Re: [Exist-open] Bug fixes in trunk concerning positional predicates

[Michael S. <so...@if...>]

The spec is totally non-intuitive in this regard.  I thought it worked
the way you had implemented it originally for quite a while and had bugs
with other processors (which were perhaps more correct).  Nevertheless,
it's a good idea to conform, so thanks.

I have to mention that I don't think /a/descendant-or-self::node()/b[2]
quite expresses /a//b[2] either, however.  Consider
<a><b/><b/></a>; /a//b[2] should capture the second b, whereas the
former expression will not.

Probably /a/descendant-or-self::b[count(preceding-sibling::b)=1] is
accurate, if inefficient.

-Mike

On Tue, 2009-03-31 at 21:37 +0200, Wolfgang wrote:
> Yesterday I committed a few bug fixes concerning the evaluation of 
> positional predicates following an abbreviated descendant step. Examples 
> include any combination of //x with a filter on the context position, 
> e.g. /a//b[2], /a//(a)[2], /a//b[position() = last()] or similar.
> 
> In all those cases, eXist did not behave as required by the specs. In 
> combination with a positional predicate, it basically treated /a//b[2] 
> like /a/descendant-or-self::b[2], which is wrong. /a//b[2] is equivalent 
> to /a/descendant-or-self::node()/b[2]: it should return the 2nd b child 
> in *every parent of b*. My solution should fix this problem without 
> loosing performance (this part wasn't easy really).
> 
> If you are using the trunk version and suddenly get cardinality errors, 
> please check your XQuery code for expressions similar to the above. I 
> did run into this issue twice today and thought I should better warn you ;-)
> 
> Wolfgang
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open