W3C home > Mailing lists > Public > uri@w3.org > January 2010

Re: non-HTTP URIs in HTTP requests

From: Gannon Dick <gannon_dick@yahoo.com>
Date: Thu, 7 Jan 2010 21:13:38 -0800 (PST)
Message-ID: <129923.53250.qm@web112614.mail.gq1.yahoo.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC