This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Incremental Processing Guidelines
- From: David Neumann <dneumann at apple dot com>
- To: XSL-List at lists dot mulberrytech dot com
- Date: Wed, 10 Jul 2002 10:33:56 -0700
- Subject: [xsl] Incremental Processing Guidelines
- Reply-to: xsl-list at lists dot mulberrytech dot com
I have a pretty huge XML file to transform, so I want to be sure
to craft my XSLT sheet to enable the incremental features of an
XSLT processor if that's possible. I've been using both Saxon 6.x
and Xalan-Java 2.4.
I've found stuff in the Xalan-Java 2.4 FAQ and in the archives of
this list; but the info I've gathered so far is anecdotal or
authoritative but limited. For example, I know that using using
counts and sorts are incompatible with incremental processing.
From a earlier exchange this year on this list I saw that
apparently using an xpath of "preceding::something" instead of
"../something" may be required for incremental processing. Plus
I've seen a few other tidbits.
One thing I'd like to use in particular is an xsl:if, but I
gather that may be a no-no?
Anyway, if there is a more authoritative list of guidelines or a
more complete set of rules of thumb, that would be a big help.
Of course, if the current answer is just trial and error, that's
also good to know. But if I do have to go that route, is there a
way to get debugging output from Xalan or Saxon so I know where
the processor is in the XML file when it starts pushing output
from translations? I've used extensions for Java callbacks in my
XSLT so I get nice feedback when either Xalan or Saxon start
transforming; it's just hard to tell whether they've sucked all
or part of the source XML. Now if I use a really huge XML file as
source for my iterative testing, I can always watch the VM memory
consumption and tell that way; but it would be nice to do my
trial and error with a smaller file.
Thanks!
d
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list