taking "child::*[position()=1 and name()='factorof']" as example:



A straightforward implementation will evaluate the child axis expression to 
a node-set and then apply the predicate to each node in the set.

A clever implementation would use the predicate to terminate the child axis 
evaluation after the first inspected node (because of position() = 1).

Not only the evaluation sequence changes but also the character of the 
expressions (a filter expression is turned into a loop termination criterion)



The serious implementation problem is to recognize optimization 
possibilities _and_ how to implement the optimization in a general way 
without destroying the clean implementation of the straightforward 
processing model.



Possible solution: Internally recognize special expressions during parse 
time and transform it to another expression which is processed by the 
straightforward processing model:



"child::*[position()=1 and name()='factorof']"
will be transformed to
"firstchild::*[name()='factorof']"
which could easily be reduced to
"firstchild::factorof'"

with the use of a processor internal pseudo-axis "firstchild".



Johannes







Wendell wrote:
>m:apply[factorof[not(preceding-sibling::*)]]

>will be better than



>m:apply[child::*[position()=1 and name()='factorof']]



at first I didn't get your point on this one. I supposed on further
consideration that it was right, although it seems like it would be
mainly dependent on the order in which xpath is evaluated by the
processor, I mean that a reasonably clever processor would evaluate
[position()=1 and name()='factorof'] first and then from there look for
any child::* which matched this, with the result that it would only
check the first child to see if it had a name of factorof?
Am I very wrong in this supposition?





XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list