The DOM and the victim, the iconoclast and the believer

[Ray Whitmer]

Didier PH Martin wrote:

[...]

A few notes to hopefully help you understand these issues.  I could be wrong on a minor
point or two, but I think my explanation is generally correct:

1.  The CORBA IDL interface of DOM is not intended to be functional, but rather only a
language-neutral way of expressing the interfaces.  It is not clear to me whether a
functional CORBA binding is useful given that if the objects are independently remote,
the efficiency problems may be too difficult, and if they are local, you probably wanted
a more-local implementation.  CORBA has not done a great job of hosting local objects.
IIOP is more robust than a local invocation.  The spec is silent on the topic, so you
apparently cannot expect local objects to interoperate between ORBs.

2.  Such an interwoven model as the DOM needs version covariance, which if you are
limited to fixed interfaces produces extreme fragmentation and loses the real type
identity of objects when you try to covary them in a graph, as is required for DOM level
2, not to mention that invariant interfaces would force the simplest navigation
operations in loops to involve typecasting for operations as every-day as checking the
namespace.  Fixed interfaces work fine in large services, but not in fine-grained object
models.  The DOM level is hierarchy-by-hierarchy, not node by node.  Discovering a level
1 node in the middle of a level 2 hierarchy would be catastrophic, yet that's all the
navigation methods guarantee if you stick with fixed interfaces without duplicating most
methods.  The so-called interface contract simply isn't adequate in this type of setting
which requires covariance.  A node is still a node within a level 2 hierarchy, even with
a namespace attribute added.  A node would not be a node within a level 2 hierarchy with
no namespaceURI attribute, even though it was a node in a level 1 hierarchy with no
namespaceURI attribute.  Intermixed success and failure of level 2 methods within a
hierarchy would be intolerable in many cases.  You check the level before you start to
perform operations, not by querying each node.

3.  Inflexible languages may wish to supply a seperate implementation for distinct levels
to solve the covariance problem.  But a good number of bindings including IIOP, Java,
Javascript, and so on can easily expand existing interfaces.  This turns out to be a very
useful balance between splintering interfaces and objects without type.  Objects have
type, but the type is guaranteed as a complete hierarchy.  Level 1 and level 2 clients
can coexist with level 1 and 2 implementations in languages with enough flexibility.  It
would be strange, for example, to force Javascript to query different interfaces for core
features clearly part of the same object just because of other languages that must do it
that way.

4.  C++ by itself lacks enough mechanism to be binary-compatible with more than one
version at a time.  Environments which expect reusability of binary objects between
shared libraries define something beyond the standard C++ language to prevent shifts in
the binary protocols.  Some fix the fundamental fragility of C++ vtables, and some do
not.  Some allow the interfaces to grow, and some do not.  Raw C++ expects no migration
of objects, so it is natural that a C++ binding would never expect to be compatible with
more than one level at a time.

5.  The common-yet-unstandardized CORBA approach of just handing C++ servants from a
separately-compiled library to a C++ client is the least-robust C++ model I have seen.
Certain CORBA C++ implementations are more robust, such as SOM-based ones, I believe.
The language bindings of the DOM are not auto-generated from the CORBA IDL -- each
binding is permitted to do what is appropriate to the language to expand the interface.
In COM, for example, an extension interface is added to an object to add methods.  Since
C++ lacks any standard solution to the problem you will find a variety of solutions
depending upon the hosting object model's binding capability, and how flexible it is.  I
have raised the issue and called for robustness in the CORBA spec (in addition to what is
already present in the IIOP spec).  But so many really are only using CORBA for remote
objects, so it isn't clear if it is a useful pursuit.  It is not hard to do in C++ if the
spec were to call for it, and it could be standardized so that local objects would be
interoperable between ORBs.

I am working on my own C++ binding for DOM right now that has none of the traditional C++
fragility problems, again, by introducing a more-robust object model, which I call CROS
(C++ Runtime Object Standard)...

Ray Whitmer
ray at xmission.com



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