[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: SAX mode, DOM mode and caching
Subject: Re: SAX mode, DOM mode and caching From: "Tangi Vass" <tangivass@xxxxxxxxxxxxxx> Date: Fri, 10 Nov 2000 16:14:34 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: SAX mode, DOM mode and caching, Kevin Jones | Thread | Re: SAX mode, DOM mode and caching, Eric van der Vlist |
use <xsl:value-of> within an attrib, Xu, Xiaocun | Date | RE: use <xsl:value-of> within an at, Linda van den Brink |
Month |