Re: Standard API to XSL processors

Subject: Re: Standard API to XSL processors
From: Tyler Baker <tyler@xxxxxxxxxxx>
Date: Mon, 11 Jan 1999 15:28:52 -0500
Oren Ben-Kiki wrote:

> I've switched some code from using Koala to XT lately, and it got me to
> wonder why there's no standard interface to XSL processors - something like
> SAX for XML. Building on top of SAX seems reasonable; something along the
> lines of:
>
> public interface XSLProcessor {
>     public void parseXSL(InputSource xslInputSource);
>     public void parseXML(InputSource xmlInputSource, DocumentHandler
> xmlOutputHandler);
> }
>
> I suppose everyone would agree this is a good thing - witness SAX's success.
> God (and the devil) are in the details, though... For example:
>
> public interface XSLProcessor {
>     public DocumentHandler getXSLHandler();
>     public DocumentHandler getXMLHandler();
>     public void setDocumentHandler(DocumentHandlet outputHandler);
> }
>
> Separates the XSL processor from the XML parser - the caller should obtain a
> parser on his own and the XSL processor takes it from there. This might be
> awkward for providing access to non-Java XSL processors (such as these built
> into some browsers), but there's something to be said for encouraging such
> processors to expose the XML parser part to Java as well.
>
> Defining such an interface does not seem to be a job for the XSL WG. Given
> that SAX is registered under xml.org, I checked whether there's an xsl.org -
> it seems that www.xsl.org exists but is under construction. Can anyone say
> anything about what xsl.org is going to be, and whether this issue is
> appropriate for it? Defining an org.xsl.sax package which would build upon
> org.xml.sax seems like the natural way to go...

I think that in general this is a good thing, but I think passing in a DOM tree
as the source tree at least and probably for the stylesheet tree as well is
definitely the way to go.  Many people will create DOM documents on the fly so
binding the XSL Processor to only streams would be a mistake.

Tyler


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


Current Thread