RE: URIs & Namespaces

Erik Wilde wrote:
> what i was asking is still in the subject line of this 
> thread: 

Sorry, it is easy to digress..

> suppose you would accept my idea of using namespaces 
> in uris (and i simply used locations here because that is the 
> use case i am currently working on), from a purely technical 
> perspective, how would you do it? 

Can you state is succintly once more?  I can envision namespaces being used
in a variety of manners with URIs i.e. as URN Namespaces, and Subdomains on
URLs, as Initial path segment on URLs, as schemes, and probably as a lot
more. So can you clarify if you mean namespaces generically in all those
manners and more, or are you speaking of a narrowly defined concept?  If the
latter, please elaborate.

> to conclude: all feedback i got so far basically said "don't 
> come up with new uri schemes anyway", which is something i 
> hear a lot. i will think about that (which may take a while), 

Excellent. The biggest downside I see to adding a new scheme is the fact
that we have a tremendous amount of deployed infrasture across the world
that understands existing schemes and by definition nothing out there to
that understands any proposed schemes.  As such, the cost to deploy new
schemes is very high, their value is very low (as per Metcalf's Law), and
thus the chance of success from widespread acceptance is lower than
piggybacking existing schemes.  Though not as "elegant", existing schemes
have an alternate beauty of being useful today.

> but supposed you http-fundamentalists out there 

That's funny. I do admit to being an "http-fundamentalists" (if there is
such a thing) which is ironic because generally I find fundamentalism
distasteful in (all?) other things... :-)

> assumed for 
> just one second that somebody would have a convincing use 
> case for (a) a new uri scheme and (b) a well-justified need 
> for namespaces within that scheme: how would you do it?

Hmm.  Assuming (a) and (b), isn't it pretty straighforward?  Something like:


But then, I wouldn't give you (a)... :)

> so i guess i was naive to just point to the iana list. could 
> you point out some omissions of the iana list and the w3c 
> list and some that are in none of both lists? i really would 
> like to get an impression of how radically incomplete and 
> detached from the Real World they are. thanks.

Also, unless I miss my guess, doesn't publish the list in a
machine-readable format (i.e. it doesn't provide a web service.)  

> could you please point out a "uri scheme" that has been 
> deployed this way (well-defined semantics bound to uris made 
> available on specific http servers with well-defined dns 
> names and some well-defined pattern to the uri's paths), i am 
> really wondering where this has happened. 

Well, you got me here.  I personally don't know of one (yet), but I very
much would like to see a first precedent.  

> and where it 
> happened in a way that not just is done by some 
> self-interested company, but instead in the way you were 
> hinting at: some community effort which is not limited to 
> just one server, and can be used by anybody interested in 
> providing access to resources of the kind that are made 
> available there. 

Actually, the best model for multiple servers are the DNS Root Servers. They
are not HTTP, obviously, but there is no reason that such a module could not
be set up for REST-based HTTP information.

Noah Mendelsohn 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:
> ate>/<z-coordinate>/ 
> Try making one and putting it into your ordinary Web browser. 
>  Something useful will happen (for some definition of 
> useful).  I'm 95% sure that software that knows about slurls 
> can use a particular slurl to navigate in Second Life without 
> openning any http connections.  

VERY, VERY Cool!  I didn't know about SLURLS.  Thanks! 

> Of course, the administrative 
> domain is a relatively heavyweight construct

Noah, can you explain why you call this a "heavyweight construct?"  Is it
because it requires DNS resolution for dereference, or something else?
Thanks in advance for educating me on this.

-Mike Schinkel 

Received on Thursday, 13 December 2007 01:12:13 UTC