Re: Why do you allow vendors to publish interfaces using org.w3c.dom

At 02:51 PM 8/14/98 +0200, Arnaud Le Hors wrote:
>Robert W. McKitrick Jr. wrote:
>
>> The W3C has broken a major rule of "Programming by contract!" In the
>> face of a changing interface (no pun intended) the W3C should insist on
>> a vendor unique package prefix (e.g. com.rwmj.org.w3c.dom). It is
>> impossible to mix code using two different versions of the org.w3c.dom
>> interfaces.

I don't understand why this would be true, and if it's true we've got a
problem.  We define an interface; I'm not a Java guru but I don't
understand why separate classes can't implement this interface and have an
application reference both classes.  

>> For example, DataChannel's DXP 1.0 beta-d and IBM's XML for Java 1.0.4
>> cannot co-exist because of this.

The W3C warns people very explicitly that if they implement based on
drafts, they're on their own -- they don't get special treatment in the
WG's to preserve the features they've implemented, and they have to deal
with incompatiblities as the draft changes on their own.  That's the
situation that DataChannel, IBM, and others are in; they chose to implement
drafts, and they have to sort out the incompatibilities.

Once the DOM is a W3C Recommendation, we will *not* make incompatible
changes to the interfaces; any obsolete interfaces will be "deprecated".
This is why the DOM spec took so long to get out, and why we've deferred so
much work for the future:  Once it's in the spec, it stays in the spec, and
applications written to the 1.0 spec will work with implementations of
subsequent versions.

In other works, don't take our cavalier attitude toward changing our minds
as the draft evolved as evidence of how we'll behave once the DOM
*standard* is published. ;~)

Received on Friday, 14 August 1998 09:20:55 UTC