The DOM: the realist and the implementer

[Ray Whitmer]

Didier PH Martin wrote:

> Hi Ray,
>
> Ray said:
> What do you feel is needed beyond the current W3C DOM standard methods for
> querying the
> levels and modules of support in a DOM implementation?
>
> Didier reply:
> Simple. An interface (even defined in OMG IDL) that allows clients to query
> the provider DOM level support.

So, to restate the question, what is the problem with the "hasFeature" call of
DOM?

> Didier reply:
> It seems that you missed something Ray. I'll be more explicit and just do
> this simple experiment Ray.

[...]

I don't see what I missed.  C++ is not set up to extend objects in a
binary-compatible
fashion.  Bindings which have a problem with that already have established
techniques for
dealing with this problem, which exactly the natural solution I expect them to
pursue.

> ---> Here is what I mean with the notion of contract.

Yes.  You constructed a fragile contract based upon fragile structures in C++.
Do you
wish to usurp the notion of contract and not allow languages and even models on
top of
C++ with more-dynamic binding capabilities to apply a more-useful notion of
contract that provides covariance within the DOM hierarchy and allows members
to be
added as long as everything the original contract expected is still there?

The correct answer in COM is to add an extension interface that can be
queried.  It is not
rocket science to apply the IDL to individual situations and adapt to the
model.  That is,
I believe, what COM DOM suppliers will do.  W3C has never committed to publish
the
standard COM binding.  That is up to whatever standards body is responsible for

specification and interoperability of COM.  Are you proposing adding extra
objects
that must be ineficiently and unreliably queried at every point to every other
binding
including Javascript, just so we can all suffer together?  When Javascript
exposes a
COM object I believe it will even reunify the COM splinters into a unified
object to
make things simple again for the user, demonstrating that the fragmented
interface is
not the only desirable one.

> Conclusion:
> a) defining the interfaces with at least an IDL and set of specification
> that defined a particular binary signature so that components can _really_
> talk together within the same address space. I do not say here that the
> interfaces should not be defined with the OMG IDL. Someone may have the need
> to ask for a DOM service at the other end of the globe :-)). Or to compile
> and convert the document in a DOM in an address space and use it in an
> other.

I think that this was way beyond the scope of the project.  There IS no winning

binary standard for C++.  DOM is one of many projects suffering under the lack
of such.  To enshrine any particular C++ binary model there as the only one
appropriate to use seems intolerant and unrealistic at best.  The body decided
to supply a CORBA template and concrete Java bindings.

The standards bodies responsible for additional object models such as COM, or
other languages with built-in object models in are responsible for creating
a standard binding of DOM at this point.

> b) Defining at least one interface that allows the client to probe the DOM
> provider. This interface is a fixed contract and do not change. This way,
> the client can query the DOM version throught a permanent interface that do
> not vary in time. Then, the client can, from the information received with
> that interface use the provider or not. Practically speaking, the client may
> understand only DOM 1, the provider may only support DOM 2, then the client
> cannot inter-operate with the provider. case 2: the client only understand
> DOM1, the provider supports both set of interfaces, the user may obtain the
> right interface set from the provider. Even if each interface do not have a
> query interface mechanism, the provider may provide the right set of
> interfaces.

This has been available since DOM level 1, I believe exactly as you propose.
I repeat the question:  what is wrong with it as it exists today.

> Note about the query interface on each node:
> you know that the DOM is, in some ways, an implementation of the composite
> pattern (gamma & al. 1995). Let's say that you have a root interface used to
> query the DOM version and obtain the root node. if the elements of the DOM
> where designed to support a query interface mechanism, then the root
> interface may, in this case, return a node interface. Now let's say that the
> DOM is an ever evolving entity and that in year 2020 the root node is not
> anymore the "document" node. Then, in this case, if the returned node is
> simply a "node" and that a query interface mechanism is provided, then I can
> query the "node" for the kind of interface desired, in 2020 that may
> probably by a "library" interface :-) Actually, within the current interface
> definitions I can't. I have to request for a "document" node, if this
> evolves into a library object, then its over, the contract is not respected
> any more. The best solution is to provide to the client a "node" object and
> then from this object obtain either a "document" or a "library" interface.
> This time the contract works. But, let's be indulgent and say that if at
> least a non changing interface is provided then a query interface on each
> interface is not necessary, the client will know that DOM level-124 (in year
> 2020) starts with a "library" interface not a "document" interface. So, in
> that case, the non-changing interface should return a typeless
> interface...hummmm, is that against the OMG interface principles. There we
> go, maybe here, a potential Y3K bug in view :-)))

Carefully adding methods to an object interface does not break backwards
compatibility at the abstract level.  A particular object model may require
specific measures such as extension interfaces to add methods to get around
limitations in the implementation or to comply with notions of the
implementation.

In cases where multiple node types are allowed, the current DOM specification
already returns node types which are checked for type.

Even if there were a generic capability to query for unknown interface types
(which is very much like a Smalltalk model where you have apparently no
idea what object type you are dealing with) it doesn't keep any better
compatibility with the level 2 DOM user who expected to deal with a
Document node, but was not prepared to deal with a Library node.
You are now arguing for fewer contracts in presumably all cases.
I'd rather add a different method to get a fundamentally-different
object type.

You will also note that in cases of clearly-distinct sets of functionality,
DOM level 2 already separates these into different interfaces, which are
obtained in object-model-specific ways such as QueryInterface or Java
casting.


> We can also say that the interfaces are simply templates, that the IDL was
> used only to please the OMG consortium and that in fact, the IDL is a fad
> not to be used in real life. OK, if the recommendation say that I should not
> take the IDL for an implementation but only as an inspiration, this is at
> least clear that I should not use the IDL for a DOM implementation. Also, if
> implicitely it is said that I can do whatever I want with the interfaces,
> add or suppress members, then why do we have recommendations then?

What wording do you propose.  How about including in the introduction:

"Note: OMG IDL is used only as a language-independent and implementation-
neutral way to specify interfaces. Various other IDLs could have been used. In
general, IDLs are designed for specific computing environments. The Document
Object Model can be implemented in any computing environment, and does not
require the object binding runtimes generally associated with such IDLs. "

It is already there.

> I hope that now you see the incongruity of the situation.

I see lots of landmines that have been in OOP in C++ for quite some time.  I
have tried to solve them for years unsuccessfully.

> Anyway, my proposal is not to judge the DOM WG which had to deal with enough
> political pressure from its members. But to help us create truly
> inter-operable components by providing enough information to implementers so
> that at least, they know what the contract is and how to fulfill it. And
> most of all, to provide to users components that are inter-operable, at
> least, within the same middleware convention. This is not even the case
> today with the actual DOM recommendations.

If you have suggestions on how to do that better, please suggest away.

Best regards,

Ray Whitmer



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.