This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Determining last node
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] Determining last node
- From: "Larry Garfield" <lgarfiel at students dot depaul dot edu>
- Date: Tue, 14 Aug 2001 16:19:57 -0500
- Reply-To: xsl-list at lists dot mulberrytech dot com
> -----Original Message-----
> Send button pressed too early: add "[1]" after all *::chapter.
> Also another minor syntax error fixed:
<snip>
> Still untested.
Xalan complained about $chNum-1 not being a variable, but once I put a space
after the 'm' it worked perfectly. Thanks! I guess I'm still having a hard
time thinking in terms of a node as a variable, and figuring out when it is
and is not split off from the rest of its siblings/parents by what
processing tags.
> Further notes: If you aim for purity, replace the chNum parameter
> by count(chapter::preceding::chapter)+1, this may degrade performance,
> however.
If it works and is specification-compliant code, that's pure enough for me.
:-) I'll save that for future reference, however. How much of a
performance difference is there between that and passing $chNum through
every template to get to that point?
> If your chapters are actually all siblings (as they are in the DocBook
> DTD) and not nested somewhere else, replacing preceding::chapter by
> preceding-sibling may increase performance a bit. Assigning
> $chapter/preceding::chapter[1] etc. to a variable might help improving
> performance for processors which are bad at CSE.
The chapters are all siblings (I'm using DocBook for the input file), but
the sect1s are not, so I decided to stick with the same code for both
sections (slightly modified, of course). It's only being run offline, so
finely tuned performance isn't a huge issue.
Thanks again!
--Larry Garfield
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list