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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Standard API to XSL processors, Sanjiva Weerawarana | Thread | Re: Standard API to XSL processors, Tyler Baker |
Entities and the DOM, keshlam | Date | RE: <xsl:template><xsl:value-of/></, G. Ken Holman |
Month |