W3C home > Mailing lists > Public > uri@w3.org > December 2007

Re: URI registries and schemes

From: Erik Wilde <dret@berkeley.edu>
Date: Wed, 12 Dec 2007 18:04:01 -0800
Message-ID: <47609311.1050205@berkeley.edu>
To: uri@w3.org
CC: noah_mendelsohn@us.ibm.com

hello noah.

noah_mendelsohn@us.ibm.com wrote:
> What about slurls, which provide http URIs for locations in Second Life? 
> See [1] for general information and [2] to play around building your own 
> slurls.  The general form of a slurl is:
> http://slurl.com/secondlife/<region>/<x-coordinate>/<y-coordinate>/<z-coordinate>/ 

interesting, i did not know that one. but isn't that more or less 
exactly like pointing to google maps and their convention for embedding 
gps into query string data? given this approach, we could just say that 
wgs84 coordinates should be represented like this:

http://maps.google.com/maps?ll=<lat>,<long>

for most people, that would probably be good, right? just don't ask 
yahoo or microsoft or anybody else. what i want to say by that: 
slurl.com conveniently works because secondlife belongs to a company and 
they can do whatever they like. i hope google have not yet reached that 
much influence to be able to say they see the world with the same eyes 
as linden labs sees second life... ;-) i see the "foundation argument" 
coming, so what you then suggest is

http://location.org/<lat>,<long>

and location.org is owned by the good guys. i still don't fully get the 
model. is that what the idea is:

- in the beginning, most browsers will actually go to location.org and 
will get whatever location.org gives them (maybe a nice page such as 
this http://explorer.altopix.com/map/popvvo/283/216/Mount_Everest.htm), 
that allows you to visit various mapping services. is location.org being 
paid to include providers on that page? if not, how do you prevent 
spammers from invading that space?

- over time, more and more browsers will understand location.org as a 
magic domain name and do some internal mapping of that uri to whatever 
they think is appropriate for locations.

- in the end, location.org can almost shut down its server, because all 
web clients know the magic prefix.

that feels just wrong to me, even though i do understand the reasoning 
behind it.

> It may also be of some use to consult the TAG Finding on Metadata in URIs. 
> [4]  Among other things, it says:

i did that, tag findings are among my favorite web documents. really.

> In this case, slurl.com is the pertinent URI assignment authority, and 
> they have provided documentation of the mapping from URI path segments to 
> positions in Second Life space. 

i would still argue that in that case it just works conveniently because 
that is a single company. i would still be interested in any example 
where that happened for something that is not owned by one company.

> I think slurls show how this approach can be practical for spaces with 
> very fine grain.  Of course, the administrative domain slurl.com is a 
> relatively heavyweight construct, but it's being applied to identification 
> of positions in Second Life space with extremely fine resolution.

i am not so much worried about the dns registration, but more about the 
fact that something like a slurl probably should not be a uri scheme 
mostly because it is a pointer into one company's commercial dataset. i 
can see the above location.org scenario working in the three steps i 
described (where the http://location.org/ prefix for all practical 
purposes morphs into geoloc: up to the point where the location.org http 
server could really be switched off and nobody would even notice).

what i don't quite get: if that is the way advocated by the w3c, why not 
simply disallow new uri schemes, and mandate that new "schemes" always 
have to be deployed in that way? you could always declare some magic 
http prefix and provide some transition support through that domain. 
personally, i would find such a "magic domain" concept becoming an 
essential part of the web architecture a bit weird, but i seem to be the 
minority.

cheers,

dret.
Received on Thursday, 13 December 2007 02:04:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC