> 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.
