Subject: Re: Standard API to XSL processors From: Tyler Baker <tyler@xxxxxxxxxxx> Date: Mon, 11 Jan 1999 22:57:11 -0500 |
James Clark wrote: > Tyler Baker wrote: > > > If someone has to build a DOM > > tree, write it out to a stream which is then piped into an XSL Processor and > > reparsed, that is an extra indirection of inefficiency that in the real world > > would knock out a lot of the potential benefits of a standard XSL API. > > But if you write it out to a SAX DocumentHandler rather than a > OutputStream or a Writer you don't have this inefficiency. I was speaking about writing things out to a stream. In the case of using DocumentHandler there is more overhead, how much more overhead I suppose is mostly implementation dependent. > Always writing out to the DOM is seriously inefficient. In many cases > it would double the amount of memory you need (two trees in memory, > rather than one). Building a DOM tree is *expensive* especially in > Java. Very true. However, you need some sort of random-access structure like the DOM to do anything useful with the XSL output. Whenever a browser renders a document, it needs to be stored in memory one way or another. From my understanding, that is one of the goals of the DOM. The way I look at it from this discussion you could have: Source + Stylesheet -> Stream -> XML Parser -> DOM Source + Stylesheet -> DocumentHandler -> DOM Source + Stylesheet -> DOM What I was trying to say is that a standard XSL API should have direct support for constructing DOM result trees, not that this should be the only support. Certainly something like DocumentHandler is a good idea. However, unless either the namespaces spec changes, or else SAX changes (I am hoping for the former), you have this namespaces quagmire to deal with which makes DocumentHandler not exactly the best choice IMHO. > If you have to choose one kind of output, a SAX DocumentHandler is the > most efficient choice. It means you have little overhead whatever you > want to do: > > - write the XML an OutputStream > - write the XML to Writer > - run another SAX filter > - build a DOM tree True, but for XSL Processors to support all of these options natively is not hard to do. At worst it requires a little delegation. > Any other choice introduces substantial overhead in some of those four > cases. True, but I am talking about the XSL API having direct support for the DOM instead as well as perhaps direct support for DocumentHandler. If an XSL Processor only wanted to support the DocumentHandler approach, it could delegate the direct support of the DOM to a SAX -> DOM package like Docuverse SDK. Tyler XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Standard API to XSL processors, James Clark | Thread | Re: Standard API to XSL processors, Oren Ben-Kiki |
Re: dl/dt/dd matching, James Clark | Date | RE: < in <xsl:eval>, David Schach |
Month |