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.
Let's first focus on a *parser* API.
>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.
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.
However, this is fundamentally *different* to the *parser* API. What
is an XML parser? What does it consume? What does it produce?
>I'm not sure exactly what you mean by "mapping documents of various
>MIME types onto XML documents" though I would be interested to know.
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?).