Re: odd NodeSet behavior

> The one big draw back of XSLT is crappy recursion.

There are ways for an XSLT processor to reduce recursion overhead -- 
recognizing opportunities to turn tail-recursion into iteration is a big 
one -- but I don't think Xalan implements much along those lines yet. Good 
opportunity for someone who has time to contribute...

Sometimes restructuring a problem can reduce recursion depth.

But, yeah, sometimes the right answer is to leave XSLT. Personally, if it 
needs stateful code I tend to leave XSLT entirely and hand-code the 
solution, but if you're willing to take the risks... One thought: If 
you've got to write stateful code, try to structure your problem so XSLT 
data dependencies will keep it from being reordered.


Getting back to the problem: When we wrote the Xalan extension mechanism, 
we assumed that most interaction between Xalan and the extensions would be 
in terms of DOM rather than xpath types. Xalan can present a read-only DOM 
view of its documents to the extensions, and knows how to access DOM 
objects returned by the extensions. (See 
http://xml.apache.org/xalan-j/extensions.html#ext-functions for a 
description of the conversions/equivalencies.) So you might want to 
consider something like having your extension accumulate its data into a 
simple array of Nodes and implement a NodeIterator which scans that array 
and can be treated as a nodeset by Xalan. That keeps you within Xalan's 
documented-and-supported extension behaviors.