Re: Standard API to XSL processors

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