Re: Collisions with identifiers in DOMError.type

On Mon, 4 Apr 2005, Frans Englich wrote:

> Hello,
>
> The changes are high that I have misinterpreted how DOM 3 Core's DOMError
> should be used, but currently I see that DOMError.typeS could lead to
> "symbol" collisions, that identifiers implementors chooses for its own
> purposes can collide with other implementors choices or future developments
> of DOM.
>
> In other words, if for code of mine decides to submit DOMErrorS of type
> "my-type", how do I know W3C doesn't pick that type name for a future
> specification, or that a user install software that also happens to use that
> identifier?

I believe that you do not have any guarantees if you use names similar to
those currently appearing in the W3C DOM specification.

I believe that the DOM WG did not consider this a major problem because 
solutions recommend themselves quite easily -- use a URI as the type string. 
I think you could be reasonably guaranteed that the W3C DOM or successor WG 
would not choose a URI that belonged to you to define as the type string 
for some extension to the DOM specification.  This would seem to be superior 
to adding a URI field, because the user only has to check one field instead of 
two, and the common W3C types still work as simple identifiers -- some
might feel that the W3C spec should have used and specified URIs, but that ship
has sailed.  I realize that it might make an implementer uncomfortable, in the
absence of a specification saying "use URIs", to use URIs because they do not
look like the specification's identifiers, but just take the moral high-ground
and use them anyway.  It is not like it is without precedent to use URIs as
identifiers in XML APIs)

I could have missed something, too.

Ray Whitmer

Received on Monday, 4 April 2005 18:14:17 UTC