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][(_at_)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][(_at_)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(_dot_)(_dot_)(_dot_)(_dot_)(_dot_)][(_at_)ID][1]
or
preceding::*[self::part(_dot_)(_dot_)(_dot_)(_dot_)][(_at_)ID][1])
and
(descendant::*[(_dot_)(_dot_)(_dot_)(_dot_)(_dot_)][(_at_)ID][1]
or
following::*[(_dot_)(_dot_)(_dot_)(_dot_)(_dot_)][(_at_)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(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list