- From: Ray Whitmer <ray@xmission.com>
- Date: Mon, 4 Apr 2005 12:14:09 -0600 (MDT)
- To: Frans Englich <frans.englich@telia.com>
- cc: www-dom@w3.org
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