Re: Standard API to XSL processors

[Tyler Baker <tyler@xxxxxxxxxxx>]

Oren Ben-Kiki wrote:

> Sanjiva Weerawarana <sanjiva@xxxxxxxxxxxxxx> wrote:
>
> >[Forwarded on behalf of Scott Boag; his mailer doesn't permit direct
> posting
> > to this list. Sanjiva.]
> >
> >It seems to me there are two (or maybe three) API's to consider here.
> >
> >1) The API to build the source tree.  SAX+ is probably fine here, though
> I'm not
> >sure it should be considered an 'XSL' api.
>
> Yes, this isn't an "XSL" api, but the XSL processor has to get its input
> somehow, and re-using SAX (at some level) seems the right thing to do.
>
> Note that it isn't clear that the source tree is really being "built". The
> first alternative API I suggested just uses the SAX InputSource; the XSL
> processor may do anything it wants with it. The second version did in fact
> build upon the SAX parser events to process the source tree and the XSL
> tree. I suspect this is too restrictive. But even in this case, the XSL
> processor may avoid building the tree, at least in theory. There is
> certainly no requirement to provide DOM-like access to the source tree, at
> least not until someone adds a really strong version of scripting to XSL :-)
>
> >2) The API to build the result tree.  My question is whether or not SAX is
> the
> >appropriate API for this.  Why are you using an API that's meant for parser
> >events?  Is SAX rich enough to capture all the XSL tree construction
> semantics?
> >Is it the ideal interface that formatters would like to see?  It may be,
> I'm
> >just questioning the assumption.  It seems to me that there's a lot you
> might
> >want to do with this API, especially for editor scenarios, and building on
> SAX
> >could be limiting.  Maybe James could give some feedback from his
> experiences
> >with XT.
>
> I was thinking in terms of _emitting_ the output XML tree, _not_ tracking
> the process by which the XSL processor is building it. That is, I don't care
> at which order the XSL processor has computed each part of the result tree
> (it might have been in parallel for all I know). I don't care which
> templates were used to create which output node, which macros were invoked,
> and so on. I only care about the result XML tree.
>
> I think that accessing the details of how the XSL processor has computed a
> particular XML tree, beyond accessing the structure of the result tree
> itself, goes against the spirit of XML. The clinching argument IMO is that
> there's nothing you might wish to do to the result of an XSL processor that
> you wouldn't, in principle, want to do to an XML file you parse from a disk
> file, which means using the SAX interface (formatting is a wonderful
> example). If SAX's interface is limiting - e.g., its lack of support for
> comments - then we should fix it.

There are several things to look at here.

You can build the source tree from a stream or else from a random access
structure.

For streams SAX seems OK.  For random access structures, the DOM seems OK.

You can build the stylesheet tree from a stream or else from a random access
structure.

For streams SAX seems OK.  For random access structures, the DOM seems OK, but
from my experience the DOM is rather weak here in terms of efficiency.  What I
would do if I received a DOM tree is reparse it into a more efficient data
structure.

You can write the result tree to a stream or else to a random access structure.

You don't need SAX to write things out to a stream, but you will probably want
the DOM to write things out to a random access structure.

In case anyone is confused, many people build DOM trees programmatically and
never need to write things out to an XML file.  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.

Tyler


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