Revelling parser writers (was Rebelling)

[Simon St.Laurent]

>I'm not sure what this means. Building a grove is not the job of a
>parser. Typically the parser outputs the events and some other process
>builds the grove from the information. The only way a parser could be
>not written to create groves is if the parser did not output sufficient
>information to build a grove conforming to a particular grove plan.

One key piece of the XML puzzle that has consistently driven me crazy is the 
lack of explanation for which part of an application is supposed to handle 
which part of processing.  A simple application might well combine the parser 
and the application, while others will provide separate services, perhaps 
allowing users to choose any (reasonably generic) parser they like, a styling 
engine, a set of linking rules, and perhaps a set of tools for viewing and 
manipulating data, perhaps even editing it.

I'd really like to see something on the order of the OSI model Rick mentioned 
that describes these possibilities and the relevant standards.  To those of us 
new to the glories of flow objects and groves, which part handles what is 
something of a mystery.  Is there a road map out there, or is it time to build 
one?

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer (January) / Cookies (February)



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)