Hehe..
I asked the same question a while ago. It seems to justify the way to
FAQ on the website.
Here is the answer I got:
1. If you already have a DOM, passing DOM directly will be faster,
smaller memory footprint.
2. If you only have a Stream, using SAX parsing will win on both counts.
Correct me if I am wrong.
Li
-----Original Message-----
From: Jeff Winter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 24, 2001 9:29 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Xalan 2.2 D7 increasing memory footprint?
I'm curious: are either of these approaches actually faster than just
feeding Xalan the already existent DOM tree and having it do its default
DTM-wrapping approach?
Thanks
-----Original Message-----
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Monday, July 23, 2001 2:08 PM
To: [EMAIL PROTECTED]
Subject: RE: Xalan 2.2 D7 increasing memory footprint?
>sample code demonstrating how to "feed" SAX events programmatically
A couple of short samples might be worthwhile, since there are a few
subtleties...
The simplest solution is to implement the SAX XMLReader interface in
your
code, so you behave just like a parser. Wrap a SAXSource around that and
pass it into Xalan, accept Xalan's call-backs to register itself as a
SAX
event handler, then when Xalan calls parse() begin issuing SAX event
calls
to that handler. This has the advantage that it's absolutely standard
SAX
programming, which everyone should understand pretty well.
There is also alternative approach, which we use when the source of SAX
events may not fully implement XMLReader, when we need that source
(rather
than the transformation) running in the main thread, and/or when we
don't
know what the source will be at the time we're setting up the
transformation. If DTMManager.getDTM is invoked with its source set to
null, we prepare Xalan's internal connections and start the
transformation
thread running -- but we don't actually establish what the event source
will be. In that mode, we return an object that implements the SAX
handler
API, and how it gets hooked up to an event source and when the events
start
flowing is the caller's problem. This approach might actually be a
trifle
cleaner for your application -- but it isn't well documented at this
time.
I'd suggest starting with the former, pending a good example of the
latter.
