Re: The DOM is not a model, it is a library!

>Virtually all DOM implementors have
>added extensions (and I respectfully disagree with Arnaud that this is
>"useless"), although this obviously limits interoperability.

I agree with everything you said except for the last portion, which have 
brought up others as well and I just don't get it:

Why does adding proprietary extensions limit the DOM's interoperability? 
Because after an _extension_, the 'core' (not in the sense of the DOM 
specification core) is still there, and this part still works in 
accordance with the DOM API as set forth in the W3C documents.

Nobody choosing a DOM implementation is forced to use its proprietary 
extensions: if you don't need it, don't use it!

I'm sure that all who have voted for reserving value ranges (e.g. for 
NodeType) for "users"  are aware of the fact that if they use them, they 
are bound to that specific implementation (as is with using every 
proprietary extension). But, leaving open e.g. a certain range of values 
for them will ensure that at no time, these proprietary values will 
collide with values defined in a later revision of the standard. This 
mechanism would ensure that their implementation will always conform to 
the standard and cannot be rendered non-conforming simply by the W3C 
suddenly specifying a different meaning for "their" value.

Leaving this door explicitly open might help get implementors to adopt 
the DOM API as the basis of their implementation efforts. Closing it by 
reserving everything to W3C could (IMHO) lead to the contrary: "Why 
should I support the DOM API at all, if I have to find clumsy 
work-arounds to be conforming and reach my goals? Then, I can as well 
settle on a fully proprietary solution." And there goes _any_ 
This is just my opinion, and as ever, I might be completely wrong here.

Christian Roth

Received on Tuesday, 5 October 1999 17:22:18 UTC