Re: Standard API to XSL processors

Subject: Re: Standard API to XSL processors
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Mon, 11 Jan 1999 19:19:32 +0200
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.

Share & Enjoy,

    Oren Ben-Kiki


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


Current Thread