- From: Erik Wilde <dret@berkeley.edu>
- Date: Wed, 06 Jan 2010 20:06:07 -0800
- To: Jan Algermissen <algermissen1971@mac.com>
- CC: "uri@w3.org" <uri@w3.org>
hello jan. > basically, I think what matters most is whether the request method is > defined for the geo: protocol. geo: is not a protocol, it's a URI scheme. there is no protocol for geo: URIs, the resources just exist (locations on earth), and the "protocol" is part of the application ("go there", "show me pictures from there", "find a route to there from where i currently am"). > I do not think that http forbids the use of non http URIs because the > client component is supposed to select the correct connector based on > the protocol. So, a geo: URI would normally never end up in an HTTP > request. that was the point. there's nothing in HTTP that keeps you from sticking non-HTTP URIs into HTTP requests, and this is what i want to do. i find this better than the magic "http://geolocation.org/" prefix preferred by others, where the semantics of the URIs are hidden in a magic prefix. my goal is to be clear about the semantics of the class of defined resources (points on earth), but to be still able use HTTP if a client wants to talk to a server about that resource. the rules governing that exchange (methods allowed and returned representations) are outside of the scope of the URI scheme, though. thanks and cheers, dret.
Received on Thursday, 7 January 2010 04:06:44 UTC