[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

SAX2 (was Re: DOM vs. SAX??? Nah. )

• From: "Bill la Forge" <b.laforge@j...>
• To: "Oren Ben-Kiki" <oren@c...>, "XML List" <xml-dev@i...>
• Date: Sat, 13 Feb 1999 09:24:03 -0500

From: Oren Ben-Kiki <oren@c...>
>Well, applying a visitor to the tree does, classically, accept the tree
>node. But in this particular case, it makes more sense to give the visitor a
>restricted view of the node. This allows us to gain all the benefits of SAX
>while still marrying the two interfaces. For the cases where access to the
>node is useful, one could add a method to the SAX API:
>
>org.w3c.dom.Element getElement();
>
>Which would return null if the visitor is applied to a "virtual DOM", such
>as in a parser, and would return the element, in case it is applied to a
>real DOM tree. Hmmm - this would introduce a dependency between the SAX API
>and the DOM API, which we really want to avoid. In some languages (C++),
>this can be avoided by defining 'org.w3c.dom.Element' to be an unknown
>"external class" without creating a dependency. In Java we could just return
>an Object... I'm certain this is solvable at some level.

(I ramble a bit in what follows, but I do get back to the topic at hand, 
eventually. --Bill)


For SAX2, it would be great to pass objects representing SAX events instead
of method calls. The overhead might not be any greater, as the parser could 
just have one of each kind of event and reuse them.

Backward compatibility could be achieved through the use of a conversion
filter, allowing existing SAX applications to work with new parsers.

There are two big advantages here in terms of extensibility:
    1. It would be easy to extend the interfaces for various SAX event objects,
        passing additional data without creating problems for an application which
        is not expecting it.
    2. Additional events could be passed which the application could ignore.

All SAX events might have a uniqued field which names the event type.
The parser interface could then provide a query method something like
        public boolean instanceOf(String eventTypeName, String interfaceName)
which could be used when the implementation language doesn't support
the instanceof operator.

An application could then route events based on the uniqued eventType field,
using the instanceOf method or operator only when a new type of event is
encountered.

We could then easily support a negotiated protocol between the parser and the
application. The parser provides a list of all the eventType fields it supports;
the application then indicates which events it is interested in.

Under these conditions, it would be easy to provide for a very close integration
between SAX and DOM.



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

• Follow-Ups:
  • events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))
    • From: Gabe Beged-Dov <begeddov@j...>

• Prev by Date: Fw: DOM vs. SAX??? Nah. (was RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
• Next by Date: XML Data Structure ...
• Previous by thread: Advantages of XML and SGML
• Next by thread: events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))
• Index(es):
  • Date
  • Thread