IDL?

[Matthew Gertner]

David,

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
DOM.

Matthew

-----Original Message-----
From: David Megginson <ak117 at freenet.carleton.ca>
To: Matthew Gertner <matthewg at poet.de>
Cc: xml-dev at ic.ac.uk <xml-dev at ic.ac.uk>
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
>arguments.
>
>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
>TCP.
>
>
>All the best,
>
>
>David
>
>--
>David Megginson                 ak117 at freenet.carleton.ca
>Microstar Software Ltd.         dmeggins at microstar.com
>      http://home.sprynet.com/sprynet/dmeggins/
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>


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