Hi, Mike,
If what you did works, that's good enough, of course. However, doing it a
bit differently might have some benefits for you.
Compare
<xsl:for-each select="page">
<xsl:variable name="prev"
select="preceding-sibling::page[position()=1]"/>
<xsl:if test="not($prev) or @tab!=$prev/@tab">
<!-- Process the nodes you selected here -->
</xsl:if>
</xsl:for-each>
to
<xsl:for-each select="page[not(@tab=following::page/@tab)]">
<!-- Process the nodes you selected here -->
</xsl:for-each>
From a human readability point of view, that's three lines shorter and
keeps the selection syntax in the for-each, so that the interior of the
for-each is purely how to process a node that matched the selection
criteria. So, to me, that's cleaner and easier to follow.
From a processing point of view, the second of these approaches processes
only the page nodes that match the criteria rather than touching every
node. Depending on the processor, that may or may not give you better
memory usage or processing speed, but it can't hurt.
From a robustness point of view, I always expect input documents to
change, so I try to write code so that at least some changes can be
accommodated without change. As Ragulf has pointed out, the first solution
won't work if the page nodes are in different order, while the second one
will. As robustness goes, it's not much, but it's something to consider.
FWIW
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--