Hi,
Thanks for the great answer.
My only question : what does it mean SAX stream being "throttled" ?
Thanks again
Yaniv.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Fri, November 09, 2001 12:57 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Fastest XSLT on my own XML like hierarchy
>
>
>
> On Friday, 11/09/2001 at 12:35 ZE2, Yaniv_Shaya
> <[EMAIL PROTECTED]> wrote:
> > I understand you are saying DTM is faster than DOM which is
> faster than
> SAX,
> > correct ?
>
> Not exactly what I was saying. Let me try again.
>
> Xalan currently uses DTM, and only DTM, internally.
> If you pass us SAX events, we use them to build a "native" DTM.
> If you pass us a DOM, we build a DTM wrapper around it.
>
> Therefore, if you already have the data in a form that you can easily
> present it via the DTM API, that may be fastest. But that
> also requires
> fairly deep understanding of DTM and of the XPath data model which DTM
> implements.
>
> If your data would require major restructuring or a particularly thick
> adapter layer to present it as DTM, or you don't have time to
> dig into the
> DTM design, or you aren't willing to accept the fact that DTM isn't
> standardized and may still be subject to change... then
> providing either a
> DOM or SAX view of your data and letting us adapt it may be
> simpler. But
> probably not faster.
>
>
> > Could you send me details/links on the DTM interfaces
>
> What we've got is the brief overview in the Xalan docs
> (http://xml.apache.org/xalan-j/dtm.html), plus the javadoc
> and the code
> itself.
>
> > and how can I use my own implementation in case I write one ?
>
> Simplest approach would be to create an extension that
> returns your data
> via your DTM implementation. That's what the SQL extension
> did... though
> that's only a partial implementation of DTM and will only support a
> limited range of uses.
>
> Next simplest might be to extend the DTMManager to recognize
> a new kind of
> source object as a request to retrieve the DTM from your code
> rather than
> building it via the parser. I don't think we currently have
> an API to allow
> plugging in a different DTMManager, but we probably should;
> if you go this
> route and want it to be supported on more than a
> local-customization basis,
> let us know and we can look at it.
>
> > Can you estimate how much faster would DTM be over DOM in case my
> underlying
> > implementation is the same ?
>
> We don't really have good numbers on that. Take a look at the
> implementation details of
> org.apache.xml.dtm.ref.dom2dtm.DOM2DTM, and think
> about how much overhead is entailed in generating the DTM
> wrapper around
> the DOM... and how much memory is consumed in doing so, which
> can affect
> performance indirectly via load on the swapper.
>
>
> > So you are saying that unless there is a "real reason" for
> the XSLT to
> > iterate over nodes, it won't - correct ?
>
> Not at the XPath/XSLT level; we request what we need from
> DTM, and only
> what we need. So it's a question of whether the DTM
> implementation is in
> turn smart enough to defer construction until it's needed.
>
> DOM2DTM always builds the DTM layer incrementally.
>
> If you feed us a SAX stream, our default is currently to
> pre-construct the
> whole DTM model. However, setting a property allows you to
> request that the
> SAX stream be "throttled", and events accepted only as needed; see
> http://xml.apache.org/xalan-j/dtm.html for details on that.
> One issue there
> is that there are arguments over whether we're allowed to throw an
> exception to terminate the SAX stream early, or must let the XMLReader
> finish. Currently we throw an exception only when we know we
> can catch it
> rather than having it returned to the caller, which would
> affect how you'd
> want to interact with us to handle the infinite docment case via SAX.
>
> Of course if you implement your own DTM, you simply return
> only the data
> that's actually called for and you're fine.
>
>
