Subject: RE: SAX mode, DOM mode and caching From: "Kevin Jones" <kjouk@xxxxxxxxxxx> Date: Fri, 10 Nov 2000 11:46:03 -0000 |
> > > > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: SAX mode, DOM mode and caching, Tangi Vass | Thread | Re: SAX mode, DOM mode and caching, Tangi Vass |
Re: rendering Xlink from a XML by u, Eric van der Vlist | Date | Re: problem selecting node sets, Jeni Tennison |
Month |