Lists Home |
Date Index |
- From: "Mark L. Fussell" <email@example.com>
- To: "Simon St.Laurent" <SimonStL@classic.msn.com>
- Date: Sat, 29 Nov 1997 15:06:16 -0800 (PST)
Simon St.Laurent <SimonStL@classic.msn.com> wrote:
> One key piece of the XML puzzle that has consistently driven me crazy
> 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
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.
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:
You may also be interested in:
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).
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)