Re: URIs & Namespaces

John Cowan wrote:
> Sean Reilly scripsit:
>> Say your GPS device has a built-in address book with an entry like the  
>> following:
>>  name: Sean Reilly
>>  home-loc: loc:55.959123,-3.191657
>>  home-addr: 48 London St, ...
>> An http: URL in a situation like that would be useless.
> Actually it would not.  You are assuming that there is nothing to do
> with an http: URL except to attempt to GET (or POST, PUT, or DELETE) it.
> On the contrary; it can also be used as a unique name in its own right.

sure, but then it becomes an identifier with a different semantics, that 
still has http: as a prefix, but never is accessed by http. that like 
saying we should send email by using http://magicmail.org/name@domain 
and demand that nobody even accesses http://magicmail.org/, but instead 
just uses the suffix for sending email. apart from "using" the http 
scheme, what is that good for? i really don't get that, sorry.

> If it is laid down, for example, that URIs of the form
> "http://geo.example.com#55.959123,-3.191657" identify a particular
> latitude and longitude by the owner of example.com, then that is
> authoritative, and there is not even a requirement on the owner to put
> something useful at "http://geo.example.com", though it is considered
> the best practice to do so.  (Note that the #... part is not sent to
> the HTTP server.)

that's like the magicmail.org. if almost by definition you say not to 
access the http server and there are some fixed semantics to the uris in 
this domain, why bind all of that to something as fleeting as a 
registered domain name that belongs to somebody and, to understand this 
magic domain, has to be hardcoded or configured into any software 
processing these uris?

i really don't see the huge advantage in that, apart from that one thing:

- magicmail.org or geo.example.com could set up a web page that informed 
people about the semantics that are built into the domain name. to be 
able to use the uris, you must then understand and implement the 
semantics, and associate them with the domain name. what that saves you, 
essentially, is looking that up in the iana uri scheme registry (where 
you would have to go if you encountered an unknown uri scheme).

all other things are exactly the same. nobody can make complexity go 
away, you can just push it around. i want to push it into a new uri 
scheme, you want to push it into some http-prefixed prefix. the real 
complexity of understanding the identifiers and acting upon them is 
something that has to be implemented in both scenarios.

cheers,

dret.

Received on Tuesday, 11 December 2007 18:01:09 UTC