xml-dev - Re: XObjects (was TLAa was SOX)

["Bill la Forge" <b.laforge@jxml.com>]

From: Michael Kay <M.H.Kay@eng.icl.co.uk>
>I cannot resist reminding you of my posting to this list on 25 Sep 1998 in
>which I suggested:
>
>public interface DOMBuilder
>{
>
>/**
>* Define the parser to be used when building the DOM.
>* The DOM implementation is free to ignore this and use its
>* own parser if it wishes.
>*/
>
>public void setParser (Parser parser);
>
>/**
>* Build the DOM document from an input source.
>* @param source The InputSource to use.
>* @return The DOM Document object that results from
>* parsing the input.
>*/
>
>public Document build (InputSource source)
>throws java.io.IOException, org.xml.sax.SAXException;
>
>}
>
>Well, great minds think alike... FWIW, I have implemented this interface for
>the DOM products from Docuverse, SUN, and IBM in a new version of SAXON that
>is not yet released.


The DomBuilder (or DOMBuilder) interface, I would argue, should not include
a setParser method--I don't see a great deal of utility in being able to switch
parsers mid-stream. Also, setParser creates a tie back to the full SAX, which precludes
a closer integration with DOM.

I've been playing with Coins/Docuverse, and here's what I've come up with so far:

package com.jxml.xml;
import org.w3c.dom.*;
import org.xml.sax.*;

/**
 * A DomBuilder object has a fixed mapping from XML elements to Java classes.
 */
public interface DomBuilder
{
    /**
     * Parse an XML document and return a Document object.
     */
        public Document
    build(Object inputSource)
        throws SAXException;

    /**
     * Returns a Document object with an empty root element.
     */
        public Document
    createDocument();
}

The assumption here is that an object with this interface is for a
specific markup language and a specific set of bindings for that markup language.

That being the case, perhaps a third method should be included:

    org.w3c.dom.DocumentType getDocumentType();

The idea of having createDocument create the root element is a carryover from
Docuverse. It may be a good idea, but I'm not adament about it.

>One reservation I do have about this discussion is that a lot of people are
>proposing using an XML document as the primary way of defining the mapping
>from element types to element-handling classes. I think there are many
>situations where that's fine, but I've also seen SAXON applications where it
>wouldn't be, because the mappings change with time or are set up by
>higher-level software. Better to define the mapping table as a Java object
>with methods to add or remove or change individual mappings; it's then easy
>to add a layer on top of this to load the mappings from an XML document in
>the case where they are sufficiently static.


I like to think of degrees of specialization:

    1.    Some applications will be based on SAX
            and not use DOM.

    2.    Some applications will be based on DOM, 
            use the DomBuilder interface, an not use 
            too much else from SAX. 

            Some of these applications may use a 
            specialized variant on DocumentHandler
            which integrates better with the DOM.

    3.    Some applications will use various bindings,
            simply by having access to more than one
            object which implements the DomBuilder
            interface.

    4.    Some applications will employ Bindings 
            (or BIND) documents.

There are many applications which will not be able
to use DOM. But I don't think that they should be our
main focus at this time.

There are going to be commercial interests which 
will focus on high-performance DOM building. It may
be wise to define some standards that accommodate
this in a timely fashion. SAX was a marvelous thing,
still wholly valid for many applications, but does
not integrate well with DOM.

I see the whole Bindings thing as being important,
especially to Coins, but not of absolute primary 
importance. I'd rank things as follows:

    1. DomBuilder interface standard. Generically applicable.

    2. An alternative to DocumentHandler which closely
        integrates with DOM. Already we see things like
        the com.sun.xml.tree.ElementNode.doneParse
        method.

    3. Bindings support. Docuverse provides a Factory
        interface, Coins uses a document, and Sun 
        has offered a dictionary of classes keyed by
        element name.

Bill


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)