XalanJ 2 SAX Thought

[Art Welch <ar...@EASTPOINT.COM>]

I have not been following the XalanJ 2 discussions closely for a while so
this may be completely irrelevant, but anyway...

My understanding is that XalanJ 2 will support directly processing a
transformation from a SAX input source. This will be done by building a high
performance DOM (DTM?) as the SAX events are received and simultaneously
processing as much of the transformation as may be done up to that point.

I had developed a solution using Xalan that was similar to this except that
it just built a regular (Xerces) DOM.

The thought is this. In my implementation to allow for very large
(essentially infinite) inputs I added an XSL extension element to free the
current node once it has been processed. This allows the user to apply their
knowledge about the stylesheet to free information that will no longer be
required. For example this works as in the following XSL fragment:

<xsl:template match="bigfatnode">
	<!-- Do stuff with bigfatnode and its children... -->

	<!-- Now done with bigfatnode so can throw it away. -->
	<myextns:freeNode/>
</xsl:template>

It would seem a whole lot simpler to allow the stylesheet to indicate
explicitly when to free nodes than to try and programmatically analyze the
stylesheet to determine this.

In testing so far this has been working quite well (but if you try to free
everything as soon as you are done with it the garbage collector kills
performance - freeing a parent node with many children works OK).

The problem that occurs to me is that the new high performance DOM may be
immutable (like DTM). If so, perhaps it may be worth while to add support
for pruning.

Just a thought... Of course if you have found a way to do without the DOM
entirely... so much the better.

I know that this is a little obvious, so has probably already been
considered. But if it has been overlooked - I can at least add that this
technique does seem to work well.

Thank You,
Art