Re: URI registries and schemes - 4

hello tom.

Tom Petch wrote:
>> if there is some need to get rid of things in the uri space, get rid of
>> urns. they serve no purpose at all. the urn: prefix has absolutely no
>> semantics other than pointing to a different registry than the one for
>> uris. retire urns, merge http://www.iana.org/assignments/urn-namespaces
>> with http://www.iana.org/assignments/uri-schemes.html, and simply say
>> that the "urn scheme" "isbn" henceforth is the "uri scheme" "urn:isbn"
>> and so on. nothing breaks, and a really unnecessary part of web
>> architecture has been safely removed. or has anybody ever seen a generic
>> urn processor that processes various urn schemes based on some parsing
>> of the urn, and then dynamically selecting the resolver for a variety of
>> urn schemes? it would still work, btw, but it would not adapt well to
>> the new web of urn-less uris... (the one thing i am ignoring here is the
>> fact that "urn:isbn" cannot be a uri scheme because of the colon, so i
>> am a bit too optimistic how easily urns could be retired).
> Mmmm, I find this strange.  Namespaces are an essential part of, I am tempted to
> say the Universe, certainly of the Internet and of other aspects of IT, such as
> most computer languages.  True, we have managed mostly without the urn: scheme
> but it does provide a namespace of namespaces, managed by an internationally
> recognised body, with a simple syntax.  Had it existed earlier, perhaps XML
> namespaces would not be such a mess (or perhaps not:-).

urns are a namespace for namespaces, but they have been placed in an 
additional namespace (the uri namespace). so urns are essentially a 
namespace for namespaces located in a wider namespace. thins originated 
when theere was the idea of urls and urns being something different that 
can and should be separated. this idea has since been abandoned (which i 
think was a good decision), and the urns are like a legacy from that 
time. i think the uro space as a namespace for namespaces is good 
enough, and the urn subnamespaces does add no value, but additional 
administrative procedures and quite a bit of confusion.

> You talk of resolution but a URN is a type of URI that need have no resolution,
> just identifying, some resource that may or may not exist.

this is the classical view 
(http://www.w3.org/TR/uri-clarification/#classical) but it really is 
hard to draw a line. http uris need dns resolution. they often need "uri 
path to file name" resolution on the server side. the fact that it is 
hard to draw a line lead to the w3c abandoning the idea of uris as being 
either urls or urns, and urls officially don't even exist anymore (it is 
just a folklore name for uris), and urns are a leftover from the 
classical times.

> Look in the Internet Drafts database of the IETF and you will find a steady
> trickle of urn definitions (which are of course also URIs) from a variety of
> organisations.

yes, but i would argue that's only because there is this feeling that 
somehow a urn scheme gives you additional benefits, whereas i really 
think all you get is a "urn:*" scheme instead of a "*" scheme, and you 
end up in a different registry, and there are no added benefits. the 
only possible advantage i could think of (in addition to a lower 
threshold for getting registered) would be some easier way to define and 
discover resolvers in the urn space, but there are no requirements for 
that to be even defined in some way by the urn scheme, so the urn scheme 
really does not provide any benefits.

cheers,

dret.

Received on Monday, 17 December 2007 17:18:02 UTC