xml-dev - Re: The DOM and the victim, the iconoclast and the believer

[Ray Whitmer <ray@xmission.com>]

Len Bullard wrote:

> Didier PH Martin wrote:
> >
>
> > a) we define all interfaces as contracts something that is stable throughout
> > the time. A contract that can be fulfilled even if the components evolve. A
> > contract that can be fulfilled in spite of the component evolution. If we
> > change the contract we simply create a new one. If we change the interface,
> > we simply create a new one.
>
> A contract is good for the duration specified.  In this case, the
> lifecycle
> intervals of redefinition;  see ISO revision cycles.  It is incumbent on
> the signatories to define what is negotiable at each interval.  The
> important
> issue is to establish a parent ROA to which all other namespace owners
> are
> signatories, therefore establishing a semantic heritage which is used to
> arbitrate disputes.

In the case of DOM, the contract is the specification, which goes far beyond
what any IDL is able to specify, although any specification may have holes in
it which need to be patched.  DOM uses IDL to help specify a how a particular
level of behavior works.  DOM generally permits specific language bindings
to do the right thing -- whatever is best -- to adapt to the requirements and
expectations of users of the platform including version compatibility.

> > b) to do so, we have a mechanism to query the interface and get the right
> > one.
> >
> > What? they say that your object broker should deal with that? Then how the
> > object broker can differentiate between two interfaces having the same name
> > but not the same specification? This is not mentionned in the OMG specs, so,
> > how can we expect that they would do it in a standard way?
>
> That is the issue.  You do not have a parent ROA.  Therefore, you have a
> contract which is interpretable in real time and no means to arbitrate.

The DOM specification tells how users of the specification can detect the
level of compliance and compatibility from the runtime system.  No small
set of models would suffice if more were to be dictated by the specification,
and would occupy no small part of the DOM WG's time to solve something
which seems more properly solvable by those concerned with a specific platform.

> > What? they say, just recompile the code. but what do we do if we do not have
> > the source code?
>
> You did not understand and/or specify your process and its
> requirements.
> Oops.

The DOM WG did not say that.  If you started with a model you cannot extend,
such as raw C++, live with it or solve it.  Different models have different
requirements and different solutions to the various problems.

> > What? they say, you're not suppose to have backward compatibility,
> > manufacturers should make some money and therefore you have to buy again all
> > the components each time a new recommendation is out. So, fine, please,
> > include this as a note to the recommendations please :-)
>
> If they say that and it is conflict with the parent ROA, then they
> are in violation of the contract.  That makes them litigable by whatever
> means is necessary.  What constitutes restitution?

Whoever said that did a poor job of choosing their object model in the first
place.

> > The believer point of view:
> > OK, the humans are born with good intentions, only the society corrupts them
> > (who said that? Jean Jacques Rousseau?).
>
> Corruption is not an issue because you will have to establish mutually
> assured interests.   What you may have is an issue of competence.
>
> > Yes indeed this is a weakness of the OMG
> > model.

Read even just the complete introduction to "What is the DOM".  It is
good reading WRT what is expected of the IDL interfaces in the DOM
spec.  While it doesn't rule out CORBA usage, it makes it obvious (to
me anyway) that using it blindly with CORBA goes outside the intent
of the specification in this case, not to mention the further-unspecified
usage of IDL for inprocess connection of separately-compiled C++
vtables, which not even CORBA standardizes.

Ray Whitmer
ray@xmission.com



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/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.