> Then, when I had to collect a range of different nodes to work with > (kind of like a preprocessing step) I created one directly and added > nodes to it. They added correctly, however I can no longer use > xsl:for-each.
> <xsl:variable name="nodebucket" > select="java:org.apache.xpath.NodeSet.new()"/> A more idiomatic and more portable approach would be to write an XPath which gathers those nodes, assign that into a variable, then use the exslt nodeset function to make that variable accessible as an XSLT node set which you could then for-each over. General tip: Try to avoid the temptation to force XSLT into using stateful non-XSLT objects. Remember that order of execution of a stylesheet is not guaranteed; optimizers may rearrange things. At best, relying on extensions may hamstring optimization; at worst, they may not be executed in the order you expect. You may get away with it in one release of a processor only to have it behave correctly-but-differently in the next release. In most cases, there really are XSLT-native ways of saying the same things, or ways which need only the well-standardized exslt extensions. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
