Standard API to XSL processors

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

Share & Enjoy,

    Oren Ben-Kiki



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


Current Thread