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