W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2005

Practical approaches for DOMError.type [was Re: Collisions with identifiers in DOMError.type]

From: Frans Englich <frans.englich@telia.com>
Date: Mon, 18 Apr 2005 13:04:34 +0000
To: www-dom@w3.org
Message-Id: <200504181304.34723.frans.englich@telia.com>


Some time ago it was concluded on this list that DOMError's attribute 'type' 
has no mechanism for ensuring uniqueness among implementations, and the 
solution in practice for that is to use URIs for the string, although the DOM 
specification does not explicitly state that.

One question to that which might arise, is what kind of URI to use. The common 
type URL is wrong, since it identifies physical files which "error types" are 
not. Errors are abstract, and that's what the chosen URI type should be 
suitable for to identify.

I looked around a bit, on IETF's urn-nid[1] list for example, and for your 
information I found two viable alternatives:

* The URI type "tag".[2] Its syntax looks in short like this: 
"tag:domain,date:arbitrary-string". For example, 
"tag:example.org,2004:xml:acme:my-product:error-foo". In other words, the 
domain name delivers uniqueness, and the addition of a date gives persistance 
in time.

* The URN namespace "fdc".[3] The principle and syntax is similar to the 
tag-uri; in broad terms substitute "tag:" with "urn:fdc".

Nothing definite, but nevertheless eventually useful, or a starting point for 
those in a similar situation.



Frans Englich
KDE Developer




On Monday 04 April 2005 19:33, Frans Englich wrote:
> On Monday 04 April 2005 18:14, Ray Whitmer wrote:
> > 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.
> Yes, that solves it nicely on the practical level. How locked in thinking
> one sometimes is.
> > 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.
> Yes, one always find  potential improvements -- but first afterwards.
> Apparently this in area which could have been better, as now concluded
> afterwards(DOMError.type should be in URI syntax). Unfortunately, I don't
> see how this can be fixed in later versions, without breaking backwards
> compatibility. The ship has sailed as you say.
> Thank you for your reply, I now know how to proceed in my particular case.
> Cheers,
> 		Frans
> Frans Englich
> KDE Developer
Received on Monday, 18 April 2005 12:55:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC