[xquery-talk] variable references in location steps

[Ron Van den Branden]

Hi,

Thank you all very much for your helpful and informative replies! I very 
well understand (and apologise for) the confused nature of my question: 
I suddenly bumped into differences between XQuery processors, and above 
all wanted to check what is the correct behaviour. From your 
explanations I gather I've become familiar with incorrect behaviour of 
eXist and will have to adjust my assumtions.

I fully agree the example was somehow contrived and will try to clarify: 
what I'm really after is the ability to:
     a) select nodes in a document
     b) select ancestor nodes containing those nodes
     c) if possible, optimize both steps by reducing actual lookups and 
bind the nodes in a) into a variable that can be reused in b)

Maybe this query is clearer:

let $test :=
<test>
   <a><el>match1</el></a>
   <a><el>match2</el></a>
   <b><el>match2</el></b>
</test>
let $match2 := $test/el[matches(., 'match2')]
return $test/a[./$match2]

On 25/02/2011 10:45, Michael Kay wrote:
> You seem to be working on the assumption that $e is not a set of 
> nodes, but some kind of function or expression which only reduces to a 
> set of nodes when it is called, and that it can return different sets 
> of nodes depending on the context when it is called.

Well, actually I assumed that variable references in location steps 
evaluated to the nodes they contain. This false assumption (I know now) 
arose from my experience with eXist, which for the query above only 
returns <a><el>match2</el></a> (while it should return 
<a><el>match1</el></a> as well, as the expression in the predicate might 
as well have been 'true()', as long as $match2 contains any nodes). This 
behaviour suggested that the predicate would select those descendant 
nodes of <a> that were defined in $match2. Apparently, this is incorrect 
and I'll have to find another way.

Actually, I arrived at this particular query formulation in an attempt 
to create flexible / reusable XQuery fragments that could be reused in 
different contexts of the search engine I'm building. In this case, it 
seems that Liam's suggestion (as the tag names for the nodes being 
matched may vary) is closest to the current variant:
     -$test/a[* intersect $match2] for selecting <a> ancestors of 
matching <el>  elements
     -$test/a/(* intersect $match2) for selecting matching <el> elements 
contained by <a>
But I guess I'll have to completely re-evaluate this approach, since the 
good performance I experienced was only due to an eXist bug.

On 25/02/2011 10:45, Michael Kay wrote:
> Looks like a serious bug in eXist to me. 

Thanks for the confirmation, I'll duly report this.

Kind regards,

Ron

-- 
Ron Van den Branden
Wetenschappelijk attaché / Senior Researcher
Reviews Editor LLC. The Journal of Digital Scholarship in the Humanities

Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
E-mail : ron.vandenbranden at kantl.be
http://www.kantl.be/ctb