- From: Gannon Dick <gannon_dick@yahoo.com>
- Date: Thu, 7 Jan 2010 21:13:38 -0800 (PST)
- To: Erik Wilde <dret@berkeley.edu>, noah_mendelsohn@us.ibm.com
- Cc: "uri@w3.org" <uri@w3.org>
Noah: 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. Erik: maybe the semweb world view is different, but that is something i want to stay away from, because it treats HTTP as axiomatic, FWIW: I'd rather not speak for the semweb world view, and vice-versa but I think this is a (hypertext) meta data transport problem. Geo Coordinates are always a Dublin Core Box (a region) because of the finite accuracy. There is such a thing as a Dublin Core Point, but it only can apply to entities such as ISO 3166 Country Codes. These are irregular "regions" with GUID's Base 26. This[1] may help to explain, from the content, rather than transport protocol perspective. A cheesey, but practical workaround would be to define html@xml:lang as [HTTP Return Code(200) | HTTP Return Code(!200)] = ["en"|"dxx"[2]]. I think that will satisfy both ways of thinking. --Gannon [1] http://www.rustprivacy.org/meta/roundtripping.pdf "Meta Data Round-Tripping & Privacy" [2] there is an ISO Code for "No Linguistic Content". I think it's "dxx". I'll look it up if it's important. > Response Code 200 > According to the HTTP specification, when a code of 200 is > received in > response to an HTTP GET request, it indicates that "an > entity > corresponding to the requested resource" has been returned > in the > response. The contents of this entity is what we understand > as a > representation of the resource. This correspondence between > a resource and > a representation is defined in [AWWW] as characterising an > information > resource. Consequently, we can assume that if we receive > this particular > response code in response to an HTTP GET request, we have > also received a > representation and that the URI references an information > resource. > ---- > > So, to the extent you take [2] as representative of the > TAG's position on > httpRange-14, it is grounded in the definition of HTTP > status code 200, > the semantics of which are independent of URI scheme. > If you're returning > a 200, you're saying that the "entity corresponds to the > resource", and I > think it's fair to say that's what the TAG says can't be > the cases for > resources that aren't information resources. > > Noah > > > [1] http://www.w3.org/2001/tag/issues.html#httpRange-14 > [2] > http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14#sec-http-rep-assoc > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > > > > > Erik Wilde <dret@berkeley.edu> > 01/07/2010 04:57 PM > > To: noah_mendelsohn@us.ibm.com > cc: > Mark Baker <distobj@acm.org>, > Jan Algermissen > <algermissen1971@mac.com>, > mark@coactus.com, > "uri@w3.org" <uri@w3.org> > Subject: > Re: non-HTTP URIs in HTTP requests > > > hello. > > noah_mendelsohn@us.ibm.com > wrote: > > I still think it's > > unlikely that, per httpRange-14 resolution, 200 > responses will be > > appropriate for geo-scheme URIs. > > so you're interpretation of > http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14 > is > that it applies to any URI? the title "Dereferencing HTTP > URIs" to me > suggests it doesn't, and it's mostly a document for the > semweb world > where people wanted to have a well-defined way of how to > use HTTP URIs > for ease of implementation, without sacrificing the > guarantee that > everything can be accessed via HTTP. my view of that > document is that it > only applies to HTTP URIs, but i don't think it clearly > says what it is > about. > > cheers, > > dret. > > > >
Received on Friday, 8 January 2010 05:20:51 UTC