[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The MONDO Approach to: Language Independent Object Serialization
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@c... i ChiMu Corporation Architectures for Information h M info@c... 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|