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.
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.
Mike Kay