xml-dev - The MONDO Approach to: Describing the Model of Information

["Mark L. Fussell" <fussellm@alumni.caltech.edu>]

The MONDO Approach to: Describing the Model of Information

Problem
=======
How do we describe the model we are using for our information?

Models always exist.  In MONDO, the information model is represented by 
the DomainModel and must exist (no matter how simple) for any 
ObjectBase.  Their is always an implicit model.  We can also provide a 
way to explicitly describe models and have MONDO use those models to 
understand information better and to validate whether it is being 
constructed (i.e. by recipes) correctly.  Explicity models can also 
provide a common human-oriented exchange format that is known to be MONDO 
understandable and verifiable (i.e. it at least makes sense to MONDO).

Forces
======
Relying on implicit models provides flexibility in describing and 
implementing the model, but directly affords no common description and 
reuse.  Providing explicit models makes sharing models easier and allows 
the information to describe itself, but could be limiting in how 
information is used.

If we do use explicit models we have the choice between using the same 
form as all other information (i.e. recipes) or a different form that is 
designed especially for models.

MONDO Approach
==============
MONDO allows both implicit and explicit modeling of information depending 
on what the producer of the information wants to describe and what the 
consumer of the information would like to use.  Explicit models are 
marked up in the same format (i.e. recipes) as all other types of 
information and the resulting model is simply an organized set of objects 
that describe another set of objects (the instances of that model).

An example model for:
    <Period
        start = <Date iso="1997-10-01">
        end   = <Date>
    >

might look like:
    <Model types=(
        <Type
            name = "Date"
            description = "A Gregorian Calendar Date"
            properties = (
                <Property name="day" type=<TypeReference name="Number"> >
                <Property name="month" type=<TypeReference name="Month"> >
                <Property name="year" type=<TypeReference name="Number"> >

                <Property name="iso" type=<TypeReference name="String"> >
            )
            constructors = (
                <Constructor ()>
                <Constructor ("iso")>
            )
        >

        <Type
            name = "Period"
            description = "A range of dates"
            properties = (
                <Property name="start" type=<TypeReference name="Date"> >
                <Property name="end"   type=<TypeReference name="Date"> >
            )
            constructors = (
                <Constructor ("start" "end")>
            )
        >
    )>

Note that the model does not describe implementation in any way, just the 
expected Types, properties, associations (non above), behavior (e.g. 
constructors), and other externally visible features of an object.

To associate a model with an instance we are just relating objects.  We 
can do it explicitly (and singularly) in the same recipe file:
    <UseModel model=<Model types=(
        <Type
            name = "Date"
            description = "A Gregorian Calendar Date"
            //...
        >
        //...
    Model> UseModel>
    <Period
        start = <Date iso="1997-10-01">
        end   = <Date>
    >

In two files but still with a single default interpretation:
    <UseModel fileName="exampleModel.oml">
    <Period
        start = <Date iso="1997-10-01">
        end   = <Date>
    >

Or in three+ files which allows multiple interpretations of the model to 
use with the recipe:
   <UseModel fileName = "exampleModel.oml">
   <Build fileName = "example.oml">

Because models are just objects we can also retrieve them by reference 
instead of direct recipe construction:
    <UseModel 
       model=<FindReference 
            <DTDReference sysid="-//HaL and O'Reilly//DTD DocBook//EN">
       >
    >

MONDO supports Models as simply the same as any other type of 
information: objects.  The only difference is their role toward other 
objects.


Benefits & Penalties
====================
Allowing both implicit and explicit models provides flexibility.  The 
only tradeoff that can occur is that people assume an implicit model is 
OK when it would be better to make the model explicit.  Other forces than 
technology should drive this choice.

There are very few drawbacks and a great number of benefits by having the 
model in the same format as all other information.  It allows the two 
core concepts (recipes and objects) to be leverage to understanding new 
facilities.  The new facilities can benefit from all the functionality of 
objects and recipes (e.g. references, encoding formats, type vs. class 
separation, properties and all other normal object abilities).  And 
because we have complete closure we can then implement and model the 
model itself in the exact same terms (recipes and objects).

Because the models are objects, the models can be arbitrarily 
sophisticated and take advantage of subtyping.  New modeling refinements 
can be extension of existing techniques.  This avoids closed-end modeling 
limitations (e.g. DTDs) while still having backward capabilities.  Also, 
the model is for the resulting DomainObjects not the recipe itself (or 
the parser) so it does not need to worry about, and will not constrain, 
irrelevant details like the actual names of recipes (e.g. "<Date>").  The 
model only cares about the Types of the resulting DomainObjects that are 
built by the recipe.

Finally, the encoding can be the same for the model as for the objects.  
This is important on a conceptual level (models are really, really the 
same things but just have a special role) and on a lower level: users 
only have to understand a single encoding (if they chose) and parsers can 
be very simple.

The only drawback might be difficulty in encoding the model in the 
standard MONDO recipe encoding formats.  Generally this is probably not a 
drawback.  Recipes allow flexibility that can be very useful for modeling 
and the encoding formats can be quite concise (plus they are inherently 
self-describing which is helpful for learning them).

See
===
The MONDO Design addition on "Modeling and Implementing, Objects and 
Recipes".
   http://www.chimu.com/projects/mondo/design/index.html#additions

Classes-as-objects is part of Smalltalk, CLOS, and (in some form) many
other interesting languages (e.g. SELF).  Generally this meta-object
capability provides a great deal of power and relative simplicity.  For
some references, see the OO sections of: 
   http://www.chimu.com/projects/mondo/links.html

SGML DTDs are somewhat the other extreme as MONDO models in encoding (very
limited), but they can still be treated as creating document-oriented
Model objects through a different encoding format.  [How SGML treats DTDs
is quite different (they constrain the parser, recipe, and the model
stage) but that is a different topic.]

The XML-Data model has similarities to how MONDO works with models.  And
the approach of XML-Data and representing models as instances was
discussed in: 
    http://www.lists.ic.ac.uk/hypermail/xml-dev/
(Search for XML-Data and/or DTD)

--Mark
mark.fussell@chimu.com

  i   ChiMu Corporation      Architectures for Information
 h M   info@chimu.com         Object-Oriented Information Systems
C   u    www.chimu.com         Architecture, Frameworks, and Mentoring


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)