RE: [xsl] sequential navigation problem (long)

["Michael Kay" <michael.h.kay@xxxxxxxxxxxx>]

> Jeni, David,
> 
> Thanks for your responses.  Thanks for pointing out the error 
> in my logic.
> 
> I am currently using the catch-all expressions, which works ok,
> 
>   (ancestor::* | preceding::*)
>     [self::PART or self::CHAP or self::SECT or self::ART or
>      self::SYMBOLS or self::APPENDIX or self::SART][@ID][last()] and
>   (descendant::* | following::*)
>     [self::PART or self::CHAP or self::SECT or self::ART or
>      self::SYMBOLS or self::APPENDIX or self::SART][@ID][1]
> 
Most decent XSLT processors are likely to optimize the [1] predicate by
stopping the search when the first node has been found; but optimizing
[last()] is much more difficult.

My first thought was to rewrite this as:

(ancestor::*[self::part.....][@ID][1]
   or
 preceding::*[self::part....][@ID][1])
  and
(descendant::*[.....][@ID][1]
  or
 following::*[.....][@ID][1])

and see if this speeds it up.

But on reflection, the [1] and [last()] predicates are redundant in a
boolean context: if there are any nodes selected, there will be a first
node and a last node. So it might be enough simply to get rid of the [1]
and [last()] predicates in your expression.

Rearranging the two branches of the "or" might also help: the biggest
cost will come when the first branch does a long search and finds
nothing. The above is probably best, but I don't know your data.

Now I'll go away and tweak the Saxon optimizer so it gets rid of a
trailing [last()] predicate on a path expression used in a boolean
context...

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 




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