The MONDO Approach to: Extending Model Functionality

Mark L. Fussell fussellm at
Mon Dec 1 14:20:39 GMT 1997

The MONDO Approach to: Extending Model Functionality 

How can we extend the functionality of our information and information 
model without becoming language specific?

Although information can be interpreted and implemented in many ways, 
frequently we will want to provide possible implementations so 
applications can automatically extend their capabilities in interesting 
new ways.

If we put the implementation into the information we will make the 
information less general.  If we provide no implementation (when we have 
one) we make the information less knowledgeable and capable than we could 

MONDO Approach
Describe implementation details in the same knowledge form as all our 
other information and loosely associate/link Classes to Types through 
possible Implementations.

We can represent a Java class as (the MONDO recipe in OML):
    name        = "COM.chimu.kernel.basicTypes.Period"
    version     = "v0.1"
    vmRequired  = "1.1"
    description = "This is a simple Period which uses java.util.Dates as 
its start and end values"
    bytecodes   = <Binary encoding=hex [[cafebabe...2000a]]>
This is readable to both Java and non-Java systems.  A non-Java system 
may not understand the bytecodes, but it can understand everything else 
and work with the information usefully.

Next we can associate this class with a particular Type in our model.
    type     = <TypeReference name="Period">
    language = "Java"
    class    = <ClassReference name= "COM.chimu.kernel.primitives.Period">

The loose association is (relatively) complete, and a particular program 
can decide whether it can use and wants to use a Java implementation of 
the Type Period.  It can also check whether the VM level is acceptable.  
We can similarly provide a Smalltalk or ".dll" implementation (assuming 
we can move the ".dll" around).

None of this had any effect on our original instance and model:

    start = <Date iso="1997-10-01">
    end   = <Date>

<Model types=(
        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")>

So they still describe "pure" general knowledge and we can still use them 
independently of all the language-localized implementations.

Generally, it is a win-win situation.  Implementation can be reasoned 
about and chosen without directly coupling it into the information 
itself.  The architecture itself is also no more complicated, but only 
has new objects and classes to represent implementation information.  A 
negative might be the added complexity of the:
associations, but the complexity can be selected as needed.  Another 
negative might be the required based functionality of an ObjectBuilder, 
but generally ObjectBuilders must be able to simply model (e.g. as an 
object with properties) anything they can not understand in more detail.

The MONDO Design addition on "Modeling and Implementing, Objects and 

mark.fussell at

  i   ChiMu Corporation      Architectures for Information
 h M   info at         Object-Oriented Information Systems
C   u         Architecture, Frameworks, and Mentoring

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list