On Monday, January 20, 2003 7:15 PM, Tyler Close wrote:
> On Monday 20 January 2003 19:10, David Chizmadia wrote:
>> I've only just started studying it, but what OMG has done is
>> define XML DTDs for expressing CDR constructs in XML documents.
>> In effect, this provides a textual representation of the binary
>> CDR format.
>>
>> The specification can be found at URL:
>> ftp://ftp.omg.org/pub/docs/formal/02-11-10.pdf
>
> Are you sure this is the right specification?

That was the specification I intended to quote, but you are
correct that it has nothing to do with this discussion. :-(

> The "XML/Valuetype Mapping Specification" defines a mapping from
> XML to IDL, not from IDL to XML. This means they have specified a
> way of representing a DOM tree in IDL. The purpose of the mapping
> is to have a way of manipulating DOM trees in IDL.  The resultant
> model is a combination of the complexity of the DOM *and* IDL.
>
> What we're looking for is a mapping from IDL to XML. The spec says
> this is covered by the MOF and XMI, but I haven't been able to
> find it yet. Those two are awfully large.

You're correct - in both the goal and the state of affairs.
Getting the IDL to XML mapping involves using the UML Profile
for CORBA, inserting the CORBA Type system metamodel into a
MOF tool and having that tool generate the XML.

Obviously not suitable. I'm sorry for the mistake.

There is an emerging specification for Interoperation Between
CORBA and SOAP/WSDL, which is defining a specific mapping between
IDL and WSDL, from which a nominal XML mapping emerges. But this
is still too hard.

>>> Technically, saying "CDR compatible" means something, whereas
>>> saying "XML compatible" is mostly vacuous[*]. But marketing-
>>> wise, the situation is reversed. The world has gotten stupid.
>>>
>>> [*] Saying "Compatible with XML DTD Foo" would be non-vacuous,
>>> but there is no standard XML DTD I'm aware of that would be
>>> suitable for this purpose.
>>
>> The neat thing about the XML/ValueType specification is that it
>> effectively allows you to say "Compatible with CDR binary or XML
>> encodings". This lets one attain the technical value of CDR *and*
>> the marketing value of XML.
>
> I am going to make a bold claim, which may be wrong. Hopefully
> doing this will help us extract information. I claim that the only
> technical advantage of CDR over doc-code is that the type names
> used in the CDR already have widely accepted meaning; whereas the
> type names in WOS are new.

In the new world of XML, I don't think this constitutes a true
technical advantage. If I had to cite one advantage that CDR
enjoys over WOS, it would be the easy availability of marshalling
code in languages other than Java - but that can be quickly
remedied!

> (The type names belong to WOS because
> doc-code has no hard-coded type names, unlike CDR.)

This is an interesting statement. Hopefully I have some time
to go back and understand what you mean. On first look, you
seem to be mixing IDL and CDR - which I claim are symbiontic,
but distinct. As far as I can tell, CDR only defines specific
representations for the IDL primitive types and doesn't have
any self-description in the representation for either primitive
or constructed types. Everything in a CDR encapsulation must
be interpreted in the context of an IDL specification.

It sounds like this is the same case for WOS and doc-code,
where WOS == IDL and doc-code == CDR.

> Note that I am not saying that doc-code has no technical
> advantages over CDR. I believe it does.

I'm inclined to believe that you're correct. At the very least,
WOS enjoys the internal coherence that can only come from not
being subjected to committee development. In addition, it was
conceived specifically for use in a capability environment, so
it should be easier to integrate with capability protocols.

-DMC

_______________________________________________
e-lang mailing list
e-lang at mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang