Re: Standard API to XSL processors

Subject: Re: Standard API to XSL processors
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Tue, 12 Jan 1999 20:34:47 +0200
keshlam@xxxxxxxxxx wrote:

>What's really needed is a standard way of binding together XML modules of
>all kinds -- parser, DOM, XSL, renderers, etc. But this seems to fall in
>the cracks between the various standards groups.

Most of the interesting stuff does that :-)

>... So the pipeline API might have to include some
>negotiation to find the best transfer mechanism.

I was initially going to say that negotation has no value since if one
component can efficiently emit one format, and another needs the other,
conversion must be done regardless of any negotiation. However, this is only
true if we consider a simple case where a "source" sends XML data to a
"processor" - a parser sending data to an XSL processor being the example we
started with.

If we want to chain two processors, one after the other, and each is
required to accept both types of input (both SAX and DOM), then we will need
some form of negotiation between them, to avoid double conversions.

How about:


// This is the equivalent to DocumentHandler for the DOM.
interface DOMHandler {
    void handleDOM(/* What should go here? */);

// This is what stands between an XML producer and an XML consumer.
// The goal is to perform the minimal number of conversions and still alow
// all possible formats to pass between the pair.
interface XMLPipe {

    // The Object should be one of DocumentHandler or DOMHandler.
    // There's no way to define this in Java beyond throwing an
    // exception for the wrong type.
    void setTarget(Object);

    // If the target is a DocumentHandler, return it; otherwise,
    // return one which will build a DOM tree and when done
    // will give it to the DOMHandler target.
    DocumentHandler getDocumentHandler();

    // If the target is a DOMHandler return it; otherwise,
    // return one which will pass on the DOM tree and
    // give the DocumentHandler events in proper order.
    DOMHandler getDOMHandler();

// An object which produces an XML tree somehow.
interface XMLProducer {

    // Will ask for either a DocumentHandler or
    // a DOMHandler, whichever suits it most.
    void setTarget(XMLPipe);

// A sample XML producer.
interface XMLParser implements XMLProducer, Runnable {

    // Where to read the XML text from, as per SAX.
    void setInputSource(InputSource source);

    // Actually do the parsing.
    void run();

// A sample XML pipe - is both a consumer (actually, two
// consumers) and a producer.
interface XSLProcessor implements XMLProducer {

    // Each of the returned objects is either
    // a DocumentHandler or a DOMHandler,
    // whichever is more suitable for it.
    Object getXSLTarget();
    Object getXMLTarget();

    // No need for a run method; all work is done when
    // the producer for the XML document calls the handler
    // methods. Requires the XSL to be given first, of course.

// A sample XML consumer. Concrete classes may implement
// either DocumentHandler or DOMHandler, whichever is more
// suitable for them.
interface XMLFormatter {
    // Whatever.

And then one could write:

// Set up the XSL -> Formatter pipeline.
XSLProcessor xslProcessor = makeXSLProcessor();
XMLFormatter formatter = makeXMLFormatter();
XMLPipe formatPipe = makeXMLPipe();

// Set up the Text -> XSL pipeline.
XMLParser xslParser = makeXMLParser();
xslParser.setInputSource(/* The XSL stylesheet */);
XMLPipe xslPipe = makeXMLPipe();

// Load the XSL processor with the stylesheet.;

// Set up the Text -> XML pipeline.
XMLParser xmlParser = makeXMLParser();
xmlParser.setInputSource(/* The XML document */);
XMLPipe xmlPipe = makeXMLPipe();

// Filter the XML through the XSL stylesheet and then
// render it using the formatter.;


This would allow arbitrary composition of XML components, which could
communicate through either DOM trees or parsing events, whichever is most
efficient for the particular combination. The code is somewhat longish but
not overly so. It should keep everyone happy.

The problem is that the above interfaces would have to be well defined by
someone. They mix
XML, DOM, and XSL, so I'm at loss to who this someone should be. Maybe Could
someone forward this and/or point me to the relevant mailing list?

Share & Enjoy,

    Oren Ben-Kiki

 XSL-List info and archive:

Current Thread