As you said: Your original document is being parsed into Xalan's internal DTM data model, which is MUCH more compact than the more common Java-object-based DOM implementation. When you import it into a DOM, it's likely to get larger; depending on the structure of the document and the details of the DOM implementation, potentially much larger.
That isn't a failure of importNode; it's a strength of DTM. The downside of DTM is that, at least in the current implementation, it it is immutable and is specifically tuned to the needs of XPath and XSLT processing. So I would suggest you think long and hard about whether your extension function really needs to recopy the full document, or if the problem can be restructured to either read from the proxy (avoiding recopying) or work on a small subtree at a time (which can then be discarded rather than having to get the entire copy into memory at once). Or if the problem can otherwise be restructured. Or if the operation you're using an extension function for can be rewritten as part of the stylesheet, so there's never a need to either expose or copy it as a DOM. If none of those options work, bite the bullet and tell JAVA you're going to need a bigger heap... ______________________________________ "... 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)
