Re: [Spam?] Why do you allow vendors to publish interfaces using org.w3c.dom

The view from another angle:

Our group's Java implementation has its own package name (still being
determined), implemented by subclassing the org.w3c.dom interfaces and
classes defined in the spec. Since the spec includes factory methods, the
user can treat our objects as if they were instances of org.w3c.dom and
everything works -- with the obvious exception of any
implementation-specific calls (such as the Document's constructor) or
application-specific extensions (which aren't portable anyway).

Yes, our package will probably "publish" a copy of the org.w3c.dom
interfaces, just so the user doesn't have to obtain that separately -- but
it should be identical to everyone else's copy at the same level and
version of the spec. If they're on a different pre-release,
interoperability is compromised anyway; if they're on the same release, the
fact that we both provide this should be harmless; the user can discard one
copy, or simply let the compiler's search order deal with it.

The point of the exercise should be that the DOM interface _isn't_ vendor
specific, and _doesn't_ change between versions of the DOM except as the
spec forces it to. And in theory, the official spec (as opposed to the
working-draft sketches) should change rarely and in controlled ways and
with an eye toward compatability, or at least formal
deprecation-and-cutover if a real change is made. (Or, as Arnaud suggested,
by recognizing that a truly incompatable DOM would really be a new animal
and calling it DOM2.)

I would presume the XML4J folks are planning to cut over to a more recent
implementation of the DOM after it's come out the other end of the PR
process.
I would hope that DataChannel plans to do likewise. Once they have,
compatability will be re-established and the problem Goes Away.


______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.

Received on Friday, 14 August 1998 10:01:39 UTC