Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "Michael Kay" <M.H.Kay@eng.icl.co.uk>, <firstname.lastname@example.org>
- Date: Mon, 12 Oct 1998 10:26:28 -0400
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:
* 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.
* Returns a Document object with an empty root element.
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:
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
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
3. Bindings support. Docuverse provides a Factory
interface, Coins uses a document, and Sun
has offered a dictionary of classes keyed by
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)