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

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

Hi,

The realist point of view:
maybe, the W3C DOM WG sees the issue of impedance mismatch between
components caused by the evolution of interfaces as an implementer issue. If
that is the case, then let's create an XML-Dev recommendation.

The implementer point of view:
Yee, we did it for SAX, let's do it for DOM components.

a) the first task is then to specify mechanism used by a DOM client to query
a DOM provider about its DOM level support. The interfaces stay as the W3C
workgroup defined it for each level.

b) Other alternative interface mechanisms are also existing for instance
DCOM IDLs (controlled by Microsoft), and XPCOM IDLs (controlled by the
Mozilla group). The original recommendations already specify OMG IDLs
(controlled by a group of manufacturer), Java interfaces (the Java language
and brand is controlled by SUN) and JavaScript (JavaScript is controlled by
ECMA). For those thinking that DCOM is evil and working solely on Windows,
then what about the WINE project and a DCOM implementation working on Linux?
So, to include in the XML-DEV DOM recommendation other DOM specifications
actually missing in the W3C recommendation. Why this? take for instance the
Microsoft implementation of the DOM. They added new members to the actual
W3C recommended interface. I cannot blame them W3C is doing the same thing
to their own recommendations from DOM versions to DOM versions. However, the
problem of incompatibility between DOM component consumers and providers is
also present in that case. Just to take this case as an example and the
impact in about 150 million machines up there in the field - just stop for a
moment and think about the impact of forgetting a DCOM specification in the
w3C recommendations - 150 millions machines. Normally, the interface should
be defined as:

interface node
{
... have the DOM recommendation members here ....
}

interface nodeEx: node
{
.... have the Microsoft extended stuff here ....
}

The latter inherit from the former. Because DCOM as XPCOM has the notion of
interface querying, then they can resolve the issue by letter the consumer
query for strctly standard compliant interface or the extended one. (Please
take note here that I not say the the extended interface is a bad thing but
that the client should be able to query for a strictly compliant interface
or an extension.)

This way, a strict DOM1 compliant DCOM client can interface with a Microsoft
component. Actually, it is impossible and the two interfaces do not match.

So, the first task for an XML-DEV recommendation for DOM components:
We need an interface definition to allow the clients to probe for DOM
support, get a DOM level 1 or DOM level 2 collection of interface. A kind of
DOM factory in a certain way. If this is present, then the interface may
change freely, the clients can obtain an interface collection compliant to
what the client understand. Other point, not to repeat W3C mistakes by
omitting important interface definition thus to include:
OMG IDL
XPCOM
DCOM
Java
JavaScript

In the case of the last two, these are languages and not interface
definition. So somebody can say why not then define Python or TCL interfaces
or object definition. They would be right and if these people are good
enough to write it, we can include it in the document.

Any suggestions? comments?
Should I instead play a lullaby and let you sleep? :-)

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.