Re: Standard API to XSL processors

["Sanjiva Weerawarana" <sanjiva@xxxxxxxxxxxxxx>]

[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.

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.

3) The API to build the style tree.  Again, SAX+ is probably fine here.

1 and 3 would appear to be just XML API's that let you build a tree.  2 seems to
me to be a different beast.

-Scott Boag






oren/37:21 AM

Please respond to xsl-list@xxxxxxxxxxxxxxxx

To:   "XSL list" <xsl-list@xxxxxxxxxxxxxxxx>
cc:    (bcc: Scott Boag/CAM/Lotus)
Subject:  Standard API to XSL processors




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








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