Re: non-http uris

hello.

Mike Schinkel wrote:
> noah_mendelsohn@us.ibm.com wrote:
>> 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...

thanks, noah, for pointing this out. this is the reason why i think that 
a uri scheme would be appropriate here. there has to be a public process 
defining what that scheme looks like, and only then will it be valid. 
this should make it much less probable to get it "wrong", but of course 
there never is a guarantee.

in the past week, i played around with the uri schemes of various map 
services (which would be more or less what noah and mike have been 
proposing with a http-based geolocation scheme), and they are pretty 
hard to match. of course they have much more features (zoom levels, map 
types, geocoding, business ids), but creating some mapping between these 
uris is surprisingly hard. my short term goal is to do this (which would 
create some sort or "virtual uri scheme" for geolocations because 
supported map service uris can be translated between services), but this 
is an ugly hack (i think) and also can easily break, because no map 
service publishes documentation about their map service uris.

>> 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. 

of course i want to go through a public process, and i hope to get some 
involvement of the community as well. the map services, however, have 
quite opposite goals, because they don't want to be turned into some 
anonymous map utility. they want their map uris to bind users as tightly 
to their service, so that they can sell ads.

>> 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.

fwiw, i did not say that i wanted an experimental scheme to be deployed. 
  btw, https://datatracker.ietf.org/drafts/draft-mayrhofer-geo-uri/ has 
been deployed unilaterally (it expired recently) and no-one seemed to 
care. the commercial players usually are not interested in this kind of 
activity, because it makes them anonymous. the geolocation folks are 
happy with their gis systems and just build web interfaces for them, but 
don't really think about merging them into the web.

i still think that location will become huge and should be treated 
accordingly, but i now that it will take a lot of time to (a) people 
convince about this, and (b) then get some agreement.

> 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}

this sounds as if i had some kind of pathological problem with http. i 
have not, but i still fail to see what should be good about http-based 
schemes, if they identify something that is (a) ubiquitous, (b) not an 
information resource, and (c) has other ways of interaction than http. 
and i do note that nobody so far was able to point to a case where such 
a magig "uri scheme" based on a fixed http-based prefix has been 
deployed successfuly. i think there is a reason for that.

the tag scheme would be the worst location. it would have the geoloc 
scheme's disadvantage of not allowing http dereferencing, and the http 
scheme's disadvantage of "hiding" the semantics in some magic prefix. i 
think we can at least agree that the tag way is not the way to go.

> 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?

i would hesitate to do this (making a transition from a http-based 
scheme to a real uri scheme) as well as unilaterally introducing a 
scheme. it is basically the same. as long as i am experimenting 
personally, i can do this with no problem. but as soon as the uri scheme 
is deployed and people are expected to use it in applications and web 
documents, it should be expected to be stable.

cheers,

dret.

Received on Tuesday, 8 January 2008 08:08:07 UTC