Re: Standard API to XSL processors

[Tyler Baker <tyler@xxxxxxxxxxx>]

Paul Prescod wrote:

> Tyler Baker wrote:
> >
> > > > You don't need SAX to write things out to a stream,
> > >
> > > If you don't write things out through SAX, then how can you write a
> > > standard-API-based post-processor without reparsing the text?
> >
> > The result tree would simply be represented by a DOM Document.
>
> I'm confused!
>
> You presented two options, writing to a stream and writing to a tree. I
> choose "stream" and point out that SAX is still the best standards-based
> way of writing the stream. Then you turn around and say that I shouldn't
> have an option at all: I should use a tree.

Sorry to confuse you.  I suppose this was my fault.  All I am saying is that you should
have three options for the result tree:

Stream
DocumentHandler (or a simliar parser event interface)
DOM Document

> > This works for XML ->
> > XML transformations but not for other things.  The idea is that the XSL Processor
> > would be responsible for constructing this DOM Document.  You could of course do
> > things the way you mentioned, but it would likely add a little bit more overhead than
> > constructing the DOM Document directly.
>
> But if I want ONLY a stream, it is MUCH, MUCH, MUCH more expensive to
> build a tree instead of outputting SAX events directly.

Of course.  I am saying that the XSL API should have native support for the three types of
result tree that I was talking about.  If an XSL implementation only wants to support
DocumentHandler, it could delegate the DocumentHandler implementation to a SAX -> Stream
implementation or a SAX -> DOM Document implementation like Docuverse SDK.

Tyler


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