Matthew Gertner matthewg at
Mon Dec 29 15:38:43 GMT 1997


Thanks for the clarification. I understand the distinction a bit better now.
As you say, the "events" received when traversing a DOM tree would be
different from the events emitted by a parser since they would contain DOM
data types. It seems to me that a standard tree iterator interface is what
we are looking for in this case (this is how we perform tree traversal in
our Wildflower SGML/XML repository). It is certainly worth discussing
whether such an interface could be derived or otherwise related to an
event-based parser backend. My gut tells me no, for the reason you mentioned
(use of post-DOM information), as well as the practical consideration that
specifying this type of interface would more logically be subsumed under the


-----Original Message-----
From: David Megginson <ak117 at>
To: Matthew Gertner <matthewg at>
Cc: xml-dev at <xml-dev at>
Date: Monday, December 29, 1997 1:14 PM
Subject: Re: IDL?

>Matthew Gertner writes:
> > Please correct me if I am wrong, but couldn't the phases in the
> > "life" of an XML document be summed as follows:
> >  Text -> Events -> Grove There is no point that I can see in going
> >  from a tree-based view
> > back to an event stream. The event stream is merely an evolution on
> > the path from text to a grove. Furthermoe, nothing I have seen in
> > the SAX proposal looks anything remotely like a simplified DOM. We
> > are talking about two complete different concepts here.
>An event-based call-back interface would be useful for automatic
>traversal of a DOM tree (rather than iterating through an
>enumeration), but the callbacks should then take DOM nodes as
>Personally, I believe that an event-based interface is almost always
>more difficult to use and understand than a tree-based interface -- it
>requires the user to manage stacks and allocate objects herself.  On
>the other hand, for advanced programmers, and event-based interface
>has important advantages:
>- it allows linear processing of very large documents with very little
>  memory
>- it can save the waste of building two separate trees, when the user
>  needs to build a different kind of tree from the XML document
>For me, then, the advantage of a common interface was not to help
>naive coders, but to provide a standardised low-level access to XML
>documents; to strain an analogy, SAX-J would be the IP to the DOM's
>All the best,
>David Megginson                 ak117 at
>Microstar Software Ltd.         dmeggins at
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
>Archived as:
>To (un)subscribe, mailto:majordomo at the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at the following
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list