xml-dev - Re: Simple approaches to XML implementation

[dgd@cs.bu.edu (David Durand)]

At 3:33 PM -0500 3/4/97, Gavin Nicol wrote:
>> First I want an entry point that allows the application to query
>> the parser implementation what property set modules it supports
>> (i.e., what's the richest grove plan available to users), and whether
>> or not validation is available.
>
>I think that this is all stuff that should occur *above* the parser.
>Given an event-driver *parser* API, you can add validation
>and grove building serices on top, for little, or not overhead
>beyond what such system would normally incur.

Yes, exactly. We may decide that some of these are so important that they
should be required from all implementations, and then we may not. But I
think it's easier and more sensible to define the event interface first.
Anyway, once we have an event-handler object, a structure holder can
generate events for it, just as easily as the event handler can create a
structure object.

>>Agreed.  However I do not think that an API specification should
>>dictate whether the grove is built from the event stream or the event
>>stream from the grove; I would regard that as an implementation issue
>>since some applications may choose to store documents as character
>>streams and others as groves (or collections of objects similar to
>>groves).  The important thing is that both APIs (event stream and
>>grove) be provided.

the event handler is an object with a lot of methods of the form:
   handle_some_event(here's the data);
  etc.

The grove object is the kind of thing that has methods like:

   Type what_kind_of_node_am_i();
   Node what's_my_ancestor();
   String what's_my_name();
  etc.

I think we should provide both interfaces, and for some language binding (I
like Java), we should implement one interface in terms of the other. But
this actually only really makes sense one way....

>This amounts to reflective API's: ie. a grove can build and event
>stream can build a grove. I have no problem with this as a general
>*document interface* API, and it's exactly what I have built in my
>various projects over the years.

And I hope we all see how trivial it would be to even provide an
implementation of both these operations.

>However, this is fundamentally *different* to the *parser* API. What
>is an XML parser? What does it consume? What does it produce?

Exactly. And here the event model is _in some sense_ the foundation.
Because parsers (even those that build trees automatically) typically
recognize events before they create structures. So if we want to maximize
the mix and match of our interfaces,  we have a parser that sends events.
And a document representation (structure) that accepts queries.

We also provide _implementations_ of an event-handling object that builds a
document representation, and the representation has a method to accept an
event handler and pass it the events correspinding to the document's
structure -- and we're there.

>Something like what I said before: given a certain level of
>abstraction, syntax becomes irrelevant. XML would be just one of a
>number of different syntaxes for the same underlying representation
>(hey, anyone remember LISP?).

Just in case that's not clear, you can parse any old format and then decide
to send XML events to represent whatever it was that the parse tree of the
foreign format had in it... presto-change-o a GIF->XML translator is born!
(now the question is how to kill it off again...)


  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)