The MONDO Approach to: Language Independent Object Serialization

Mark L. Fussell fussellm at alumni.caltech.edu
Mon Dec 1 14:23:17 GMT 1997


The MONDO Approach to: Language Independent Object Serialization

Problem
=======
How do we serialize Objects so we can later read them back into a program 
of either the same language or a different language?  Also, how do we 
allow humans to easily create, read, and modify these objects (i.e. 
include human languages)?

It is common to need a simple way to save a web of objects and later read 
them back in to the same program or a different one.  Sometimes the 
programs will be of the same language (e.g. both Java) and sometimes they 
will be different.  The later is much more complicated, especially in its 
most general form (any object to any language).  A variation on the 
inter-language movement is from human writable language (through text) to 
a computer language.  Usually this is restricted to very simple 
information (e.g. String properties) or document-oriented information 
(e.g. HTML/SGML).

Tradeoffs
=========
If we do not have a single interchange format we will have multiple ones 
and the complexity will be higher.  If we can not describe objects in a 
cross-language format than languages will be unable to interoperate with 
this mechanism.  If we can not describe object information in 
human-readable formats than humans will be less likely to understand the 
process and will be unable to participate in the general capabilities 
(e.g. they can only work with simple property files).

A single, general, object interchange approach would allow all movements 
of objects to be easier to both computers and people.  On the other hand, 
if we try to design a general approach that becomes too cumbersome it 
will not be useful to the many common needs of applications (i.e. same 
language serialization and simple property files).

MONDO Approach
==============
Encode information as "recipes" to build objects.  Describe the most 
general information first: what to build and what "ingredients" (recipes 
for other objects) it needs.  Next describe the language independent 
model of that information.  Finally describe the possible implementations 
for that model in different languages.  Any of these steps (other than 
the first) can be left off but it results in less ability to move between 
languages.

Also, enable "recipes" to be easily convertible to a human readable and 
writeable form: usually as marked-up text files in any one of 
XML/SGML/OML (the last being oriented to objects and MONDO, an Object 
Markup Language similar to XML).

Some simple examples of recipes (in OML and no models yet) are:
----------------------

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

----------------------

    <Map pairs = (
        <Pair key='speed0' value = ('speed0.gif' '(Speed0)' 4 11)>
        <Pair key='speed1' value = ('speed1.gif' '(Speed1)' 4 11)>

        <Pair key='remote'   value = ('remote.gif' '(Link to Remote 
Location)' 11 11)>
        <Pair key='local'    value = ('local.gif' '(Link to Local Page)' 
6 6)>
    )>

----------------------

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

----------------------

    <mode name = "section-reference"
        bindings = (
        <When element = "note"
              build   = <!Recipe (
            <Paragraph  
                font-size = "12pt"
                content   = <Sequence
                    font-weight = "bold"
                    content     = "Warning:">
            >
            <process-children>
            ) !Recipe>
        >
        <When element = "title"
              build   = <!Recipe <process-children>>
        >
        //...
    >

----------------------

  <P {VTL's company philosophy and strategic direction
    are set by <A href="lmanley.html" {Luke Manley}>,
    the company's President.  The following is a summary
    written by Luke on what he views as the key elements
    to VTL's success. } P>

=======================

All of the above, when by themselves, rely on the reading and "building" 
application to interpret and implement the information model.  This might 
be suitable for language specific encoding of information or when the 
model is very standard.

But we can also explicitly add model information, for example:
   <!-- ExampleModel.oml -->
   <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")>
            )
        >
        //...
    )>

And loosely[1] link it to the actual information:
    <UseModel fileName="exampleModel.oml">
    <Period
        start = <Date iso="1997-10-01">
        end   = <Date>
    >

Alternatively we can use well-known models, which allow wider interchange 
without moving recipes:
    <UseModel 
       model=<FindReference 
            <DTDReference sysid="-//HaL and O'Reilly//DTD DocBook//EN">
       >
    >
    
    <UseModel 
       model=<FindReference 
            <Reference id="com.sun.java.jdk1_1.standardClasses">
       >
    >

================

The next step is to be able to connect specific implementations to the 
models, but this is covered in a different MONDO approach statement: 
"Extending Model Functionality"

Benefits
========
We have a very general way to encode information so multiple 
applications, programming environments, and people can understand it.  It 
is simple to parse and process for a computer and for a person.  We have 
also cleanly separated the information from the specifics required to 
instantiate that information in any given programming environment.  But 
we can encode general models for the information in the same format 
(complete reflectivity and closure) and take advantage of them if the 
application desires.

We can take advantage of sharing models and information through public 
references to objects/recipes or by "shipping" recipes along with the 
information.  This supports both a push and a pull model of moving 
information, models, and implementation between applications.

Inter-language movement is inherently supported, as well as inter-version 
(e.g. JDK version) movement.  The choice is up to the application how 
well the information is described vs. how much the receiving application 
will be responsible for interpretation.

General document markup, objects, and information modeling are aligned 
and we can take advantage of the concepts, patterns, designs, and 
abilities of all of them.

Penalties
=========
MONDO is a newer approach that is different from industry specific and 
language-specific approaches.  More overhead than language specific 
binary approaches [this could be lessened or removed by using binary 
recipe encoding format].  Possibly slightly more overhead than simple 
text property files, but is much more general.

See
===
The MONDO Design document, an especially Chapters 1-5.
   http://www.chimu.com/projects/mondo/design/index.html

For related technology see the Smalltalk file-in format, LISP, Java 
serialization, CORBA and the ODMG OIF specification.  Some resources for 
these can be found at:
   http://www.chimu.com/projects/mondo/links.html


Notes
=====
[1] Actually, we can be even looser than that using a separate 
"interpretation" file.
[2] I ran over 3 pages by a couple paragraphs :-(  I guess the DSSSL
example pushed me over.

--Mark
mark.fussell at chimu.com

  i   ChiMu Corporation      Architectures for Information
 h M   info at 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 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)




More information about the Xml-dev mailing list