Lists Home |
Date Index |
- From: email@example.com (Gavin Nicol)
- To: firstname.lastname@example.org
- Date: Tue, 4 Mar 1997 15:33:32 -0500
> 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 email@example.com the following message;
List coordinator, Henry Rzepa (firstname.lastname@example.org)