There are 3 defining design points to take into account when discussing type
conversions:
1. source schema
2. sink schema
3. binding mechanism between source and sink at runtime
The JSR #31 uses #1 as fixed (from the binding mechanism generator's
perspective) XML schema/DTDS, #2 as generated Java classes, and #3 as Java
code. Not surprising that programmatic-centric Sun would want to use Java
as the sole source of information for the bindery. Of course, if either #1
or #2 change, then the bindery has to be regenerated and class-loaded.
I've been lobbying for combinations and permutations of these, in particular
fixed source and sink schema with XML definitions driving the binding
process.
Additionally, for generic binderies to be created, there must be the ability
to specify graphs of objects/relationships to be bound/transformed into the
different schemata. I have been unable to find relevent graph specification
languages other than RDF for use in either EJB finders or XML Link graphs.
Some of the CORBA externalization work looks interesting.
Mark, you know that for some time (since Nov 97) I've wanted to be able to
write Java code like:
stream.writeXMLObject(myEJBRoot, graphSpecification, EJB2XMLBindery);
However, there are many technical problems with a generic bindery, some of
which are:
o Conversion between the type systems is usually lossy, ie XML->Java->XML
via JSR 31 would lose all PIs and comments. PIs are rather important for
schemas and stylesheets
o Reference mechanisms are too different and hard to parameterize, ie
conversion from EJB graph to XML document and how to deal with circular
references.
A few additions that I've tabulated in my talks about xml in transformations
as specifier and source/target:
UML<-->XML
XMI
Database<-->XML
Oracle IFS
Java<-->RDB using XML driven bindery:
Oracle 8i
One of my IBM solutions YAEJBML
Java<-->XML using XML driven bindery:
MDSAX
HTML<-->Java using XML driven bindery:
JSP
WIDL
Cheers,
Dave Orchard
Technical Architect, IBM
XML Link co-editor
> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Sunday, August 22, 1999 5:35 PM
> To: Mike Spreitzer
> Cc: fork@xent.com; dist-obj@distributedcoaltion.org
> Subject: Re: More chaos coming down the pike
>
>
> Hi Mike,
>
> Mostly just wanted to archive this on FoRK and dist-obj, but I had some
> incidental comments to offer too ...
>
> At 01:41 AM 8/22/99 -0700, you wrote:
> >Sun and the OMG are preparing to standardize two more arcs (XML schema
> >-> Java and XML schema -> OMG IDL, respectively) in an already large
> >and inconsistent graph of data modelling languages. Below I have a
> >very partial listing of data languages and mappings between them.
> >
> >I recommend (and have sent essentially this same message to the
> >responsible bodies) that new standardization efforts should take this
> >larger
> >picture into account, and strive for maximal consistency with the
> >explicit mappings and implied (via composition) mappings already
> >extant. As the mappings already extant are not consistent, this
> >immediately tells us that new mapping standards should leave some
> >choices to an external "mapping choices" document.
> >
> >A possible motivation for the XML schema -> OMG IDL mapping is the desire
> >to be able to easily import into the CORBA world standards already
> >developed in the XML world. But it is also interesting to be able to
> >easily import into the XML world standards already developed in the
> >CORBA world. This says that the XML schema -> OMG IDL mapping needs
> >to be *onto*, not just *into*, OMG IDL --- that is, it should be
> >possible to map some XML schema into any given IDL. Similar
> >considerations apply to the XML schema -> Java effort.
>
> Absolutely. I hope you're planning to contribute to the JCP!
> Luckily, surjection is already a goal.
>
> >
> >While the "marshalling framework" of the proposed XML Data Binding
> >specification "is not in any way intended to displace the object
> >serialization mechanism that is already a central part of the Java
> >platform", perhaps it should be a generalization.
>
> Just to be clear, there is no XML Data Binding specification at this point
> in time, just a strawman discussion paper to kickstart a JCP.
>
> > Another reason to
> >generalize Java serialization is that there is no inherent reason that
> >a given Java object should have only one serialization, which (as far
> >as I know) is a limitation of the current facility; I already have
> >heard colleagues complain that they want different serializations for
> >different purposes.
>
> The 1.1-based JDKs support a single serialization (java.io.Serialization)
> mechanism at as you point out, but luckily it's mildly extensible via
> java.io.Externalizable - perhaps not ideally so due to the lack of
> implementation MI, but close enough.
>
> Still, there's some value in a single format. Without it, I have to worry
> about dynamically loading in the code necessary to reconstitute the object
> graph when I stumble upon it. Does the cost of the need for variety in
> formats outweigh the value of at least declaring a de-facto standard? I
> personally don't think so, and therefore appreciate that Java has a single
> format (even though I wish it were something else).
>
> >Languages that can model Data:
> >
> >UML, OMG IDL, Microsoft IDL, Java, C++,
> >XML Schema:
> > DTD,
> > SOX <http://www.commerceone.com/solutions/xml/sox/sox.htm>,
> > XML-Data <http://www.w3.org/TR/1998/NOTE-XML-data/>,
> > XML-Data-Reduced <http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm>,
> > DCD <http://www.w3.org/TR/NOTE-dcd>,
> > DDML <http://www.w3.org/TR/NOTE-ddml>,
> >RDF & RDF schema,
> >SQL
> >
> >
> >mappings between languages:
> >
> >Java<->bytes:
> >
> >Java serialization
> >RMI-IIOP
> >
> >
> >Java<->XML:
> >
> >XML Data Binding
> ><http://www.javasoft.com/aboutJava/communityprocess/jsr/jsr_031_x
> mld.html>
> >
> >a hypothetical "Java archive" facility, mentioned in the XML Data Binding
> >JSR above
> >
> >CommerceOne's SOX->Java mapping
> >
> >IBM XML BeanMaker
> ><http://www.alphaworks.ibm.com/aw.nsf/techmain/98D0F921C80C8ED688
> 2566F30070
> >3F7C?OpenDocument>
> >
> >Coins <http://www.jxml.com/coins/index.html>
> >
> >KOML <http://www.inria.fr/koala/XML/serialization/>
> >
> >
> >OMG IDL<->Java:
> >
> >OMG Java->IDL
> >OMG IDL->Java
> >
> >
> >XML<->OMG IDL:
> >
> >Forthcoming OMG Request For Proposals (from the ORBOS task force)
> >
> >
> >Microsoft IDL<->Java:
> >
> >Microsoft
> >
> >
> >XML<->Microsoft IDL:
> >
> >Microsoft SOAP / Userland XML-RPC
> >
> >
> >OMG IDL<->Microsoft IDL:
> >
> >Chapter 18 in CORBA 2.3
> >
> >
> >
> >UML<->IDL:
> >
> >Rational Rose
> >
> >
> >UML<->Java:
> >
> >Rational Rose
> >
> >
> >XML<->Database:
> >
> >IBM's XPK4J
> ><http://www.alphaworks.ibm.com/aw.nsf/techmain/7B29BBCB9A1C1C1A88
2566F30070
>3F83?OpenDocument>
>
>IBM's DataCraft
><http://www.alphaworks.ibm.com/aw.nsf/techmain/12CD979739AB8E968825671B0065
>A4A6?OpenDocument>
>
>
>RDF<->XML:
>
>W3C's XML-based syntax for RDF, in RDF spec
><http://www.w3.org/TR/REC-rdf-syntax/>
>
>
>RDF schema <-> XML schema:
>
>subject of debate in W3C
>
>
>More than two sided:
>
>WDDX <http://www.wddx.org/>
>XMOP <http://jabr.ne.mediaone.net/documents/xmop.htm>
>
>
>
>Mike Spreitzer <spreitze@parc.xerox.com>
>http://parcweb.parc/spreitze/ (Xerox internal)
>http://www.parc.xerox.com/spreitze/ (external)
>+1-650-812-4833
It'd be nice to see a full blown survey of the above. Anybody know of any?
Got any plans to update "Towards a Web Object Model"[1] Frank? 8-)
[1] http://www.objs.com/OSA/wom.htm
MB