RE: non-http uris wrote:
> > > It's quite possible that it's conveniently meeting the short term 
> > > needs of early users, while sacrificing potentially 
> important long 
> > > term benefits such as integration with the browsable Web, etc.
> > 
> > Just curious, is that a general principle but not for these 
> specifics,
> or
> > specifically related to this question? 
> I think you're asking whether there's always a tension 
> between getting things out for early experimentation, vs. 
> getting things right in the long term.  

Nah, I know there pretty much always is that tension...

> I don't claim any 
> special expertise on that question, but there's a related 
> question that I know the TAG is concerned about:  scheme 
> names are a precious resource, in a very particular sense.  
> Unlike DNS names, which are hierarchical, or GUIDs, which can 
> be minted freely, scheme names have no substructure, no 
> distributed means of allocation, and yet they must be used 
> unambiguously.  The same is true for many other short names 
> in the Web architecture, such as the link type [1] values of 
> rel= attributes, the types and to some degree the subtypes 
> that comprise a media-type, and so on. 

So the take away is that if there is anything we are going to play with a
scheme name is one of the most sacred?  By analogy, maybe we should consider
it to be similar to changing laws vs. amending the US Constitution; the
latter is and should be a much higher barrier? 

> The problem with Erik putting out an experimental geocode 
> schema, in my opinion, is that he may not be the only one 
> with that idea.  Maybe now, or a in a few years someone will 
> come up with a better one.  Perhaps Erik will only allow for 
> 2 dimensional coding and someone will decide that height is 
> important.  Perhaps he'll get the resolution "wrong".  Well, 
> if he'd just made up a namespace or an HTTP URI, anyone else 
> could just make another one.  Once he's started getting 
> people to deploy URIs of the form "geocode:xxxx,yyyy" then 
> for all time that must be the only use of that scheme.  
> Otherwise, when you come upon a link, you won't know whether 
> it's an "old" one based on his conventions, or a new one.

I agree with the concern, but it doesn't keep the self-interested from doing
it, does it?  (I'm lamenting here...)  I don't think Erik would be in that
category but some of the leading tech companies in the industry certainly
have been...

Of course the counter is that sometimes it might be necessary for those
leading tech companies to do something unilaterally because of the
difficulty of getting the TAG to consider an issue important if it is not
currrently high on their agenda. (This is not a criticism of TAG, just a
recognition of human behaviour and bandwidth.)  


> > Do you have a current opinion on what would be best, or do you just 
> > think it needs a lot more exploration?
> Well, if at all possible, I'd try to use http-scheme URIs.  
> Insofar as there's a deep belief that a separate scheme is 
> needed, I would try to go through a very careful process of 
> requirements gathering, community discussion, debate, etc. 
> leading up to an IETF RFC or W3C Recommendation. 
> What I'm very reluctant about is to see a scheme go out for 
> experiemental use until such careful design and debate has 
> happened. There are many aspects of Web architecture with 
> which it is easy to deploy experimental implementations.  
> Unless I'm missing something, the tradeoffs in experimenting 
> with new schemes are much trickier.

I'm with you. Too bad Erik has such an aversion to http-scheme URIs,
especially since I think he could easily get it working with http-scheme
URIs in a manner that would be compatible with a geoloc: scheme.  He could
start with the former, go through the process in parallel, and then later a
recommendation could be announced to transition from http-scheme URIs to
geoloc: scheme if and when it makes sense, i.e. htpp://geoloc.{domain}/{loc}
=> geoloc:{loc}

Actually, wouldn't this make sense to propose to TAG that they consider this
a best practice process for anyone wanting to introduce a new scheme?

-Mike Schinkel 

Received on Tuesday, 8 January 2008 07:19:39 UTC