xml-dev - RE: The DOM: the realist and the implementer

["Didier PH Martin" <martind@netfolder.com>]

Hi Ray,

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

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.

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.

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.

If that is the case, if we want something quite general, and because the
interfaces definitions change from recommendation to recommendation and
therefore any contract between clients and providers is changing. Then, the
proposal is made that, a new interface (i.e. a template,  not a C++ template
:-)) is added to the DOM recommendation. At least, the DOM component
providers on certain early binding environments like for instance XPCOM or
DCOM or whatever can implement this interface to announce the support level.
This way, no more crashes. Off course, certain late binding environment may
not have this problem, in that case this interface may be superfluous.
However, if we agree on a certain non changing interface to announce the DOM
component capabilities, this may be useful on certain platform.

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.
}

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).

As long as this interface do not change in time, we are OK, an XPCOM or DCOM
DOM client using early binding won't experiment a crash. This could also be
said of an OSF RPC but, there not a lot of these in the field ( :-))

Thus, a WINE implementation of a DOM component may provide this interface
and prevent client crashes, idem for an XPCOM client. As long as this
interface do not change.

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
:-)))

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

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@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@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.