IDL?

[Matthew Gertner]

Having silently followed the discussion on this list for many weeks, I am
delighted to see the latest initiative to produce a parser backend
specification which is both simple and elegant. I have also been following
the DOM activity very closely, and I very much agree with David on this.
There needs to be a clear distinction between what the goals of this list
are (besides a lot of very stimulating discussion) and what the DOM is
doing. David's suggestion 1) makes this distinction very clear, whereas 2)
is somewhat of a mystery to me.

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.

I am not suggesting coupling SAX too closely with the DOM or making anything
dependent on the DOM release. What needs to be made clear is that if you are
going from text to events, you need SAX (and this might be all that is
needed for a lot of apps which are interpreting XML as a real-time event
stream), and if you want to work on a grove, you need the DOM. If you need
to go from text to a grove, a single SAX implementation of a DOM builder
would be sufficient to support ALL parsers using SAX. This seems to be the
killer synergy we are looking for, doesn't it? Why would you ever want to go
from a nice, clean grove representation back to parser events? (This is not
rhetorical -- I really think I need enlightenment here).

Anyway, chalk up one strong vote for 1).

Matthew

-----Original Message-----
From: David Megginson <ak117 at freenet.carleton.ca>
To: xml-dev at ic.ac.uk <xml-dev at ic.ac.uk>
Date: Saturday, December 27, 1997 9:08 PM
Subject: RE: IDL?


>Peter Murray-Rust writes:
>
> > >1) (My suggestion.)  A pre-DOM interface, defining the events returned
> > >   by an XML parser, and providing enough information to build a DOM
> > >   tree (PIs, attributes, elements, data, DOCTYPE declarations, etc.).
> [...]
> > By "pre-DOM" I assume you mean:
> > - valid only until the DOM comes into effect
> > - (possibly) a subset of DOM functionality.
>
>Actually, I am using it in a linear-processing model (you must view
>this with a monospaced font like Courier):
>
>* David's Model:
>
>  PARSER --> SAX-J --> DOM --> [tree-based user application]
>               |
>               --------------> [event-based user application]
>
>In other words, a DOM builder would be just another an event-based
>SAX-J application.
>
> > >2) (Tim's suggestion.)  A post-DOM interface, for people who don't
> > >   want to learn the complexity of the DOM, and providing only the
> > >   minimum possible information (elements, attributes, and data).
> >
> > By "post-DOM" I assume you mean "will not be onsoleted by the DOM",
rather
> > than "cannot be put into operation until the DOM.
>
>In this case, I am using a slightly different model:
>
>* Tim's Model:
>
>  PARSER --> DOM --> SAX-J --> [event-based user application]
>              |
>              ---------------> [tree-based user application]
>
>In other words, SAX-J would be just a simpler event-based API for the
>DOM.
>
>I don't see a very pressing need for the latter -- tree structures are
>familiar to coders, whether or not know anything about XML -- but I
>would be happy to implement it if requested (I do not want to exclude
>PI's, however, since that will exclude the possiblity of using
>architectural forms and other standards working on top of XML).
>
>Is this what everyone else is expecting?
>
>
>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)