The DOM: the realist and the implementer

[Ray Whitmer]

Didier PH Martin wrote:

> Hi Ray,
>
> Ray said:
> So, to restate the question, what is the problem with the "hasFeature" call
> of
> DOM?

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:
> I already explained all this in a previous post on XML-dev. to restate it
> briefly:
>
> a) case one: we banish everything that is not Java, JavaScript or created
> with a CORBA IDL because everything else is not defined in the DOM
> recommendation. This is not very practical since there is alternative
> middleware or other languages than the one listed.

This seems to be a straw man.

> b) we consider the DOM recommendation as a template. The data types may vary
> (the DOMString is only an example, string may be different in different
> languages) but, we use the DOM as a template. As long as the function names
> are respected and that we can package these functions is something that
> resemble an interface (i.e. an object, etc...) it is OK.

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.

> So, let's now say that it is (B). It will be an interpretation since it is
> not explicitly said anywhere. Contrary to that, everywhere in the
> recommendation is displayed CORBA interfaces so, this may lead to think that
> this is the official religion and other stuff is heresy. Anyway, let's play
> the supreme court judges and say that our jurisprudence is that the DOM
> recommendation are simply templates are that the CORBA interfaces are simply
> guidelines.

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.

> Let's make a concrete proposal (again the interface here is based on the (b)
> interpretation and could be taken as a template)
>
> interface DOMComponent
> {
>         boolean HasFeatures(....); // we have here the same parameters as in the
> DOM specifications
>         object QueryDOM(DOMString); // could be actually "DOM1" or "DOM2" returns
> an object (i.e. could be actually a "document" interface and in year 2020 a
> "library" interface. so we say here an untyped object. Each platform may
> adapt this to its world.
> }

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.

> Thus, a client first ask for this interface to query for the capabilities,
> then obtain with the QueryDOMInterface the first node. The algorithm is:
> a) Obtain the DOMComponent interface (in XPCOM or DCOM get it from the class
> factory)
> b) Get the DOM component capabilities with the HasFeatures member
> c) if the required feature is present, then use the QueryDOM. We could have
> said here queryDOM interface or QueryDOMObject. But in some environment it
> may be an object for other an interface, so let's make it more neutral with
> QueryDOM. This latter member returns an object (i.e. an interface).

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.

> But, instead of adding this interface we have always the alternative to say
> that XPCOM and DCOM is heresy and that everybody that is using that should
> be burned in hell. If that is the case, please, give me at least some time
> to email my fellow colleagues at Mozilla.org to ask for a refugee status
> :-)))
>

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.

> PS: I have read your page on CROS and look forward reading more an hopefully
> experimenting with it in the future.

I hope to do great things with it.  But if it doesn't become something that meets
requirements much better than what we have now (which doesn't seem too hard right
now, after an extensive search) I will abandon it myself.

Best regards,

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.