The DOM: the realist and the implementer

Didier PH Martin martind at
Mon Jan 17 19:27:29 GMT 2000

Hi Ray,

Ray said:
I did not see an explanation of that before, nor do I see one below.  You
proposing something that seems very equivalent to hasFeature.

Didier reply:
Sorry Ray, it seems that the problem is out of range of your understanding.
I do not not now what is the something that you do not understand. Maybe
before going further you can read a bit about XPCOM (ref: or DCOM (choice here get the doc at microsoft site
or code for Linux at WINE site which URL I do not remember) Yes it indeed
keep the same kind of result as HasFeature but resolve the problem for XPCOM
and DCOM early binding DOM component.

Ray said:
Add to this, that players in each domain SHOULD standardize their specific
bindings.  It does less good if there are multiple COM implementations out
there.  I
COM because there apparently _are_ multiple incompatible COM implementations
there.  To the best of my knowledge, no independent implementor of the spec
tried to
sit down at the beginning and write up the COM binding as an open public
so we can expect that they are not interoperable.  Blame the W3C if you like
for not
wanting to explicitly produce every standard binding, but the generic
already moves slowly enough without the added weight.  I place the blame on
implementors who had interoperability as a requirement and failed to follow
with a standards document.  It should have been obvious as they privately
made up
interface and class identifiers and did not standardize them with others
similar efforts that they would not be interoperable.  If they did not have
interoperability as a requirement, then that speaks volumes by itself.  If
thought it was W3C's responsibility, well, they were mistaken.  They should
have at
least published a note to the W3C, and I still hope someone does so that all
other implementations can be judged as private tinkering never designed to
interoperable, and implementations designed to be interoperable will be.

Didier reply:
Yes I agree with you Ray, I ven asked several month ago (or years?) why is
the COM IDL not included in the recommendations and got fuzzy answers
denoting some political issues behind the answers (surely not technical
ones). Off course, my intent is to ûblicaly publish a COM and XPCOM idl so
that ambiguity is resolved once and for all (hopefully, I do not have 30 000
people working for me nor do I have billions in revenus but at least has the
decency to provide my component users a clear contract).

Ray said:
They are much stronger than guidelines, but they cannot reasonably dictate
all the
idiosyncrasies that a particular language or object model binding has to
in order to accomplish interoperability.  That has to be done
It must be standardized to be effective.  That doesn't mean that W3C ever
to do all the work for all bindings themselves.

The tools are there, but the standards work only starts when a DOM spec is
released.  Please note that this attention is required regardless of the
level 2
issues of adding methods to interfaces.  It had to start with level 1, or it
certainly won't work with level 2.

Didier reply:
For any CORBA compliant ORB these interface definitions are implementable,
for everything else, only templates.

Ray said:
Seems quite unwieldy and unnecessary to me.  While this is similar to how
COM solves
the issue, it seems unnecessary in Javascript, for example.  There is less
or haphazard modification to DOM interfaces than your posting implies.  A
Java, COM,
Perl, Javascript, or other DOM binding can be extended for level 2 without
too much
trouble such that a level 1 application never knows the difference, while
subjecting the user to unreasonable crossed-over baggage from other object
Counterexamples will be gladly examined.  There already are mechanisms in
DOM for
solving these situations where they crop up, but "core" functionality is
"core" so
that the application doesn't have to wonder with every new node whether it
available.  I find it extremely unworkable to have to query node-by-node for

Didier reply:
Who said node by node you? surely not me read again the posting. I said an
interface to query the capabilities of the component. Not an interface to be
added to any interface. Most of all, it is not all middleware that does
support the queryInterface mechanism. So, let's forget it. The only
sufficient thing is to provide an interface that the client where the client
can query the component capabilities, obtain the first node (which as I said
can change in times - ref: example of the actual "document" root which could
eveolve into the "library" root node). After you get the root node (of
wahtever class or type if may become) you have what the actual or current
recommandation states. The mechanism is only to provide for early binding
middleware a non changing interface so that client can probe the component
capabilities without experimenting any crash. Off course, new middleware as
your can provide a better answer than XPCOM or COM but it remains that for
those using these middleware, a robust solution has to be provided. And this
solution is not to tell them, go buy or use a CORBA ORB.

Ray said:
Something like this is fine for COM.  I don't think I would choose exactly
model, even for COM after having heard lots of arguments.  And it is clearly
inappropriate for some languages.

Didier reply:
OK ray, what would you propose for COM then. I am listening. Hoops I forgot,
your solution has also to work with XPCOM too. OK, I am all hears to what
you'll say.

Ray said:
This is not at all what was being proposed.  It is proposed that COM extend
interfaces in a way that COM is designed to be extended, and that others do
same, adequately standardizing and publishing the required binding-specific
to make it interoperable.  How methods are added is only one of many issues.

Didier reply:
What are you talking about Ray? You said that, I never proposed this. I am
trying to find a solution for a problem experimented with DCOM and XPCOM
based components (using early binding) and propose a solution which is
better than a system crash to know if the component provides or not the
service. We could have used the CLSID but this does not necessarily work
with XPCOM. So, the solution is a compromise for both world.

Didier PH Martin
Email: martind at
Conferences: Web New York (
Book to come soon: XML Pro published by Wrox Press

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.

More information about the Xml-dev mailing list