[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: sequential navigation problem (long)
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|