[topicmapmail] xpath: stop at first match

[Carlo Moneti]

On 2006.08.02 13:01 G. Ken Holman wrote:
> This is the last I'll say on the topic as it seems we are speaking from 
> different perspectives.  I only want to rectify a false assertion.
> 


>>> [Ken wrote] Two people, myself included, have told you that the 
>>> following specifies what you want:
>>>   /topicMap/topic[@id='$id'][1]
>> 
>> Well, not really. Also, I was well aware of this option beforehand. 
>> Frankly, the position() function is not relevant, not in function or 
>> intended purpose.
> 
> Excuse me?  It absolutely solves your issue in processors that 
> implement lazy evaluation.  You want the first, in document order, of 
> all those topic children with the given qualification, thus 
> "[position()=1]" which is abbreviated as "[1]".  That is what the above 
> expression states, and a processor can choose to take advantage of the 
> information provided.

You are right---in so far as some processors implement lazy evaluation. 
But I was speaking from the perspective of the xpath spec, which provides 
position() as an addressing/selection scheme, and does not provide an 
option for or require "stop-on-first-match" functionality.

>> But I'm suggesting a new feature.
> 
> I disagree, so we remain at different perspectives.  The above 
> expression *implies* stop at first match because the "position()=1" 
> predicate explicitly states "only the first in document order" ... 
> there is no other interpretation of "[1]" other than "[position()=1]".

I agree with you that position()=1 *implies* stop at first match. But 
it's not explicit in the xpath spec. And you have confirmed that xpath 
implementations vary in this regard. So not all implementors have 
interpreted this as we have. I imagine we agree that 
"stop-on-first-match" (or 2, or 3,...) is a desirable functionality. 
Maybe it should be in the spec? I don't care whether it's the default or 
an option.

>> In fact, it can only be implemented as an option because only the 
>> programmer >>knows when a query is for a unique item.

This may well be an incorrect statement on my part. I'm not an 
implementor, and it wasn't based on a thorough analysis. A quite 
unnecessary statement.

I'm sorry we got stuck on this. In reviewing my initial post, it seems to 
sum up my question well. You have answered my questions, and I thank you 
all, especially Ken.

Best Regards,
Carlo