RE: [xsl] XSL: For-Each Efficient or Not?

[Johannes Döbler <jd at aztecrider dot com>]

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