Re: non-HTTP URIs in HTTP requests

hello noah.

> Right, but you're asking about using geo-scheme URIs as the Request-URI 
> for an HTTP request, and HTTP >is< a protocol.  Your HTTP request will 
> necessarily have a method -- assume for the moment that method is GET. The 
> question is whether the GET method can be meaningfully implemented on your 
> resource, or more to the point, which status codes are sensible in in 
> responses.

you're right that an HTTP exchange about geo: URIs needs rules, but 
these can be (and i think should be) separate from the geo: URI scheme 
itself. and currently i am just trying to make sure that there's nothing 
in HTTP itself that keeps me from using HTTP as a protocol for non-HTTP 
resources.

> For example, if your HTTP response has a 200 code, then the response 
> implies that your geo resource has a "representation", which is by the way 
> included in the response.   If you decide that you what your geo-scheme 
> URIs identify are some sorts of documents (perhaps a map centered on the 
> point designated), then it seems clear to me that a 200 response to a GET 
> is appropriate, and you can send back the image of the map.

what i am looking for is to keep that decision out of the scheme itself. 
for some scenarios, that representation (the map image or HTML embedding 
that image) may be useful and appropriate, for others that may not be 
the case. HTTP also does not make any assumptions about the 
representations available for resources, it only gives you a way to ask 
for one and get one if there is one. which is exactly why i want to use 
HTTP.

>  If (as I 
> suspect) geo-scheme URIs identify points on the surface of the earth, as 
> opposed to map documents, then I'd guess that a 200 is likely 
> inappropriate, but a 303 "See other" might well be a way to point people 
> to information about that point (maps, elevation, rainfall, whatever).

for some applications, map imagery may be appropriate, and google maps 
has proven that this representation (even though it's limited in its 
coverage of what a location "is") is hugely useful for a lot of people.

> I'm 
> not convinced that a physical point on the earth "has a representation" in 
> the HTTP/AWWSW sense.  See permathread on httpRange-14, etc.

maybe the semweb world view is different, but that is something i want 
to stay away from, because it treats HTTP as axiomatic, which is a 
constraint i am not interested in. i think for practical purposes there 
are many possible representations of geolocation points, and while there 
may not be the one that is authoritative and/or exhaustive, there are 
many use cases in which it makes sense to build interactions around 
representations of geolocation points. my current goal is to figure out 
how to best use HTTP as the protocol for these interactions.

thanks and cheers,

dret.

Received on Thursday, 7 January 2010 18:30:16 UTC