xml-dev - The MONDO Approach to: Extending Model Functionality

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

The MONDO Approach to: Extending Model Functionality 

Problem
=======
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.

Forces
======
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 
have.  

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):
<JavaClass
    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.
<Implementation
    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:

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

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

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

Tradeoffs
=========
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:
   instance--[interpretation]--model--[implementation]--classes
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.

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

--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)