The DOM: the realist and the implementer

[Didier PH Martin]

Hi Ray,

Ray said:
I did not see an explanation of that before, nor do I see one below.  You
were
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:
http://www.mozilla.org) 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
mention
COM because there apparently _are_ multiple incompatible COM implementations
out
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
standard,
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
standard
already moves slowly enough without the added weight.  I place the blame on
COM DOM
implementors who had interoperability as a requirement and failed to follow
through
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
making
similar efforts that they would not be interoperable.  If they did not have
interoperability as a requirement, then that speaks volumes by itself.  If
they
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
the
other implementations can be judged as private tinkering never designed to
be
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
establish
in order to accomplish interoperability.  That has to be done
language-by-language.
It must be standardized to be effective.  That doesn't mean that W3C ever
intended
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
arbitrary
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
not
subjecting the user to unreasonable crossed-over baggage from other object
models.
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
is
available.  I find it extremely unworkable to have to query node-by-node for
core
functionality.

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
your
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
the
interfaces in a way that COM is designed to be extended, and that others do
the
same, adequately standardizing and publishing the required binding-specific
details
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.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind at netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.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.