RE: SAX mode, DOM mode and caching

>
> > > It is well known that XSL processors are usually faster in SAX
> > > mode than in DOM mode : XT is a good example.
> >
> > You need to be clear about what you mean here. All current XSLT
> processors
> > use a internal object model that may be a DOM or a proprietary model. If
> you
> > pass SAX events as input the processor still builds an object model. I
> don't
> > think there is any generic reason that creating an internal model from
> > SAX events should be any quicker than from a DOM.
>
> I don't know much about the internals of all the current XSLT
> processors but ...

That was a bit general :-) Perhaps I should have said that no implementation
I am aware of has declared that its using anything other than an internal
object model.

> 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.

>
> Tangi
>

Regards,
Kev.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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