Simple approaches to XML implementation

[Gavin Nicol]

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

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?).


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