[topicmapmail] xpath: stop at first match

[G. Ken Holman]

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.

At 2006-08-02 12:35 -0400, Carlo Moneti wrote:
>On 2006.08.01 21:44 G. Ken Holman wrote:
>>At 2006-08-01 21:05 -0400, Carlo Moneti wrote:
>>>A "stop on first match" option in xpath 
>>>strikes me as a highly useful feature. And, in 
>>>my case, my code would be tighter and more 
>>>consistent. I'm sorry to get confirmation that it doesn't exist.
>>In my opinion, W3C and ISO standards properly 
>>specify results, not behaviours.  Products 
>>compete on the implementation of their own 
>>behaviours to produce the specified results.
>
>See bottom
>
>>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.

That is why two people have told you the above is what you need.

>>It would be inappropriate for a standard to 
>>dictate *how* that is implemented.  In the XSLT 
>>world the Saxon processor returns the first 
>>without looking beyond, while I believe (though 
>>I'm not positive) the XT processor obtains all 
>>and then returns the first of them.
>
>That's interesting. Then Saxon must provide a 
>setting or query syntax for this, I presume?

False.

Saxon XPath addressing is lazily evaluated.  When 
you address something, it remembers what you are 
addressing but doesn't actually go and look for 
anything until it is needed, because by the time 
it is needed, not all that is addressed might be returned.

In the case of "/topicMap/topic[@id='$id'][1]" 
the processor can determine the cardinality of 
the final result as being "0 or 1", before going 
to the source node tree ... therefore, when 
searching the source node tree, it can determine 
when it finds the first that there is no need to 
keep looking, because the cardinality has been 
fulfilled.  Hence, the "lazy evaluation": it 
doesn't bother obtaining all items and then only 
returning the first, because it knows how many are being searched.

A processor that does not implement lazy 
evaluation will evaluate all components of the 
address as and when encountered, thus incurring 
excess execution time by searching all topics and then returning the first.

I tell my XSLT students when shopping for 
processors to select those that implement lazy 
evaluation because of the improved impact on performance.

>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]".

If your processor chooses not to take in that 
piece of information and work with it, change the 
processor, don't change the specification.

Good luck in your work with XPath ... I hope you 
have found this exchange worthwhile.

. . . . . . . . . . . . . Ken

--
UBL/XML/XSLT/XSL-FO training:         Vårø, Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman at CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/t/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/t/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal