Re: SAX mode, DOM mode and caching

Kevin,

> > XT can work in two different modes: SAX and DOM.
> > In both modes, the stylesheet is parsed into a proprietary DOM-like
object
> > model (OM).
> > In the SAX input mode, an object model is still built but only for the
> > events used by the current processing, ignoring the non-relevant ones.
>
> This where I get lost. Looking at com.jclark.xsl.sax.BuilderImpl I
> can see no evidence of node filtering based on 'current processing'. It
> just builds a complete om. Can you point me at some docs, source or
> otherwise which shows this.

I looked at com.jclark.xsl.sax.BuilderImpl also and you seem to be right.
It sounds like I've prejudged, trusted blindly or misread something. Next
time I'll check by myself first before asserting things in a mailing list
;-)
This is a good news for me, it means I can easily cache the result of the
SAX parsing, without having to create a kind of SAX events queue.
... but I still don't understand then why XT is so much faster in SAX mode
than in DOM mode.

James Clark (in XT doc), talking about SAX and DOM for the input :
"XT will be much slower when using the DOM than when using SAX directly, so
you should not use this unless you already have a DOM tree as a result of
some other processing."

I think I'll soon reverse-engineer seriously XT : neither the sources or the
javadocs are very verbose.
I begin to re-eval my idea about good object codes needing no comments ;-)

Thanks,

Tangi


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list