Revelling parser writers (was Rebelling)

[Mark L. Fussell]

Simon St.Laurent <SimonStL at classic.msn.com> wrote:
> 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.  

You may want to look at the MONDO architecture and processing model.  Its
components and flows (IMO) subsume all the processing models I have seen
for SGML and XML documents.  It is also unusually flexible and general. 

The basic "forward" (from text to application functionality) flow is:
   1. [Parser]           Parse the text (say XML) and turn it into a 
recipe (what objects to build and what ingredients to use)
   2. [ObjectBuilder]    Build the recipe and construct objects within 
the ObjectBase
   3. [ObjectBase & App] Interact with the resulting objects

Note that the recipe is usually virtual: The interface between (1) and 
(2) could be approximated with parse event notifications.  The interface 
between (2) and (3) is done (usually) with Factories that know how to 
build particular types of objects.  As an example of an ObjectBuilder, a 
GroveBuilder is a particular type of ObjectBuilder that builds a 
Grove-based object model (possibly using a GroveObjectFactory).

---

At the point of (3) the application can do whatever it wants, but it is 
likely to want to:
   3.a. Visit the objects [traverse from one to another doing some task]
   3.b. Inspect their properties
   3.c. Modify the objects or ask for more sophisticated behavior
   3.d. Create new objects that transform the old ones

   3.e. Produce changes to the world outside of the ObjectBase.  For example:
      3.e.1  Present the objects to the UI
      3.e.2  Write the objects to a database
      3.e.3  Convert the objects to an external stream

Although not complete, the above describes common behavior that 
applications are likely to want to do with information.  

The high level architecture and component responsibilities can be useful 
for organizing an application.  There are also well known techniques and 
available code for all of these pieces of functionality.  MONDO itself is 
supplying an architecture, frameworks, and some of the functionality 
listed above.  But many tools could do the same work.

======

Another good source for architecture and flow models for SGML/XML is:
    Developing SGML DTDs: From Text to Model to Markup. 
        Eve Maler and Jeanne El Andaloussi. 
        Prentice Hall, Upper Saddle River, NJ, 1996.
        ISBN: 0-13-309881-8

This is one of my favorite SGML books.  It describes how to think about 
and put together SGML processing systems from the for-everyone basics to 
large-scale system issues.  It also very readable.

======

For information on MONDO, see:
   http://www.chimu.com/projects/mondo/

You may also be interested in:
   http://www.chimu.com/publications/oopsla96tutorial23/

That tutorial slides may be a little impenetrable if you can not see the 
connection to an XML/SGML flow.  SGML/XML and the MONDO architecture 
populate the DomainModel layer of the system.  The rest of the 
architecture then shows how you can present or store that DomainModel.  
The architecture may look a bit like overkill but it actually reduces to 
simpler models easily or parts can be fully realized without much pain  
(for example, by using a good MVC UI framework).

--Mark
mark.fussell at chimu.com




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)