Re: Range article

>>Every implementation of W3C's Document Object Model will include their
own
>>extensions to the implementation.

Maybe I'm missing the point, but it seems to me that there's less to this
statement than meets the eye.

There's a very long tradition of "mining" code for useful undocumented
methods. Of course doing so means sacrificing portability -- often
including portabilty to future releases of that same package.

There's also a long tradition of implementation-specific documented
extensions. Some are filling gaps in the APIs, or proposing/prototyping
functionality which may be added to the API in the future. Some are adding
behavior specific to that particular application set. Again, portability is
a concern.

>programmers find that in order to get the job done they need more that
>what the Recommendation calls for.

Sometimes, yes; the DOM Level 2 Recommendation doesn't yet provide a way to
discover whitespace-in-element-context, for example. Sometimes it's a
convenience/performance feature, and someone happened to decide to
implement it directly on the object rather than on a helper object. And
again, the portabilty issues are self-evident.

None of this is DOM-specific, and I don't find any of it surprising.


Certainly we should keep an eye on what's being done in the way of
extensions, and consider whether any of them are general/important enough
that the DOM ought to pick them up.  But if folks insist on coding against
specific implementations, we can't stop them... and I'm not sure we ought
to try; this might actually be the right trade-off for their intended
problem domain. We should probably advise them to encapsulate calls to this
custom code, so they can reimplement this isolated function should they
move to a different DOM... but I don't see a way to do more than that,
other than to simply continue DOM development.

______________________________________
Joe Kesselman  / IBM Research

Received on Tuesday, 27 March 2001 16:45:32 UTC