xml-dev - RE: The DOM and the victim, the iconoclast and the believer

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

Hi David,

I did not made that test with Java but I think that if I do a call to an
interface's member that does not exist, Java throw an exception. Am I right
to say that? So, in the case of Java, we have to implement an exception
handler for non supported members if we want our code to be robust when
consuming a DOM component. If that is the case, let me think of the
advantage of having each time an exception handler for non-supported members
compared to an interface providing the DOM capabilities. On the first
thinking pass, I do not see any advantages.

So, even if CORBA do support exception handling (1), to use such mechanism
to discover the capabilities is not quite good. However, if I understand you
well, you propose to use
Node.getOwnerDocument().getImplementation().hasFeature() for such service.
Did I understood well? If that is the case, I am not able to find the member
"getImplementation" in the DOM specs. Or maybe, you make a proposal for
capability discovery here, is it the case? This implies that we modify again
the node interface to add the member "getimplementation". Or maybe you
meant the "support" member that appeared in DOM 2. So, in fact, we can probe
for the right capabilities only since DOM2.

Let's wrap this up.

a) Actually, if I understand you well, CORBA has for early binding (as well
as for late binding) a mechanism for impedance mismatch between components.
if a member is called and not present in the interface, an exception is
thrown. So far, so good for CORBA implementations.

b) Now for DCOM or XPCOM implementations. a) we consider them out of the
recommendation or non compliant to DOM1 and DOM 2 recommendations since the
interfaces are not encoded in the CORBA IDL and mapped with a CORBA
compliant ORB to a language (for instance C++). b) we consider DCOM and
XPCOM as a compliant implementations and if this is the case, then, we have
a problem since DCOM do not throw exceptions for early binding, only for
late binding. And XPCOM is for the moment only for early binding. Then, in
that case we have a problem with impedance mismatch.

c) if only a CORBA compliant implementation is compliant with the DOM
recommendations then the Mozilla XPCOM or Microsoft or WINE DCOM
implementation of the DOM is non compliant and therefore cannot be called a
DOM 1 or DOM 2 compliant implementation since it is not implemented nor
distributed with a CORBA compliant ORB. If that is the case, only a CORBA
compliant implementation is OK, a Java implementation is OK and a JavaScript
is OK. Everything else not developed with CORBA compliant ORB is not OK.
Then, is java and JavaScript specifications OK even if not generated nor
distributed with a CORBA ORB? Gee, there are some contradictions here


d) The ORB IDL and the java and JavaScript specifications where just
example. There is no obligation to use a CORBA IDL to generate the right
code. The proof of this is that there is no actual CORBA to JavaScript
mapper (Is there any?). IN that case, there exist component specifications
such as XPCOM or DCOM for early binding that may crash if an impedance
mismatch occurs between the provider and the consumer. In that case, and
mainly for early binding, a new non changing interface is required to probe
for capabilities. Obviously we have to provide a mechanism which is backward
compatible. Thus, this mechanism has to allow a client to probe for level
one or level two support (or level n). This even if the DOM 2 recommendation
included in the node interface such probing mechanism but this mechanism is
not part of DOM1, therefore, it is not backward compatible and may cause
problems to COM component consumers, especially the consumers using an early
binding mechanism.

So, basically, either we bannish forever XPCOM and DCOM implementations
(goodby WINE, goodby Mozilla) saying that they do not fit in the CORBA, java
or javaScript world. or that we say that these where only templates,
examples. In this case, we need a non changing interface for consumers to
probe the DOM component capabilities. This mechanism has to work for any DOM
implementation since the DOM 1 recommendation.

David, I am having a hard time to know what is and what is not compliant
now. However, if an XPCOM or a DCOM implementation could be said to be
compliant to a DOM 1 or DOM 2 recommendation, then we need an interface that
does not change to query the DOM capabilities since the node interface seems
to change at each DOM recommendation. And, with XPCOM and DCOM early binding
client, I will get a crash if the wrong interface is addressed. Off course,
I can say that the client is responsible to deal with any situation, etc...
but why not make life easier and have a single place telling the client what
kind of contract is supported by the provider. And again, in the case of
XPCOM or DCOM implementations, and if these latter are said to be compliant
DOM implementations, then this is required since these component protocol
cannot handle interfaces that change all the time.

PS: thanks for the tips about interface inheritance.

----------------------
(1) I am still searching where it is written for early binding - For late
binding, this is obviously the case - I want to put an hand on the exact
location in the specs where it is written for future references.



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.