Jeni Tennison wrote:
Nathan,
Yes, that's correct. With no constraining Accept headers, it could alternatively return HTML
with embedded RDFa with a <link rel="describedby"> element, for example.
Is that universally true?
Suppose /uri identified a PDF formatted ebook, or a digital image of a
monkey in JPEG format, or even an RDF document.
Question A:
Currently we have:
<http://example.org/uri> - a JPEG image of a monkey.
When you issue a GET on that URI the server currently responds
200 OK
Content-Type: image/jpeg
Link: <http://example.org/uri-documentation>; rel="describedby"
So under this new proposal, the server can return the contents of
/uri-documentation with a status of 200 OK for a GET on /uri?
If yes, this seems like massively unexpected functionality, like a
proposal to treat "Accept: some/meta-data" like a DESCRIBE verb, and
seems to exaggerate the URI substitution problem (as in /uri would be
taking as naming the representation of /uri-documentation).
If no, where's the language which precludes this? (and how would that
language go, given that it's exactly the same protocol flow and nothing
has changed - other than the reader presuming that /uri now identifies
something that does have a representation that can be transferred over
HTTP vs identifying something that doesn't have a representation that
can be transferred over HTTP).
Question B:
How would conneg work, and what would the presence of a Content-Location
response header mean? Would HTTPBis need to be updated?
Question C:
Currently 303 "indicates that the requested resource does not have a
representation of its own that can be transferred by the server over
HTTP", and the Link header makes it clear that you are dealing with two
different things (/uri and /uri-documentation), but where does this
proposal make it clear at transfer protocol level that the
representation included in the http response is a representation of
another resource which describes the requested resource (rather than it
being as the spec defines "a representation of the target resource")?
Either way, there is no implication that what you've got from
http://example.org/uri is the content of http://example.org/uri (or that
http://example.org/uri identifies an information resource), but there is an
implication that what you get from http://example.org/uri-documentation is the
content of http://example.org/uri-documentation (and that
http://example.org/uri-documentation is an information resource).
Sorry I don't follow, how is there an implication from a 200 OK for
<uri-a> that it's not an IR and for <uri-b> that it is an IR?
If there was a Set of all Things (Set-A), then that set would have two
sets, "the set of all things which can be transferred via a transfer
protocol like HTTP" (Set-B), and then everything else (Set-C) which
comprises Set-A minus Set-B. As far as I can tell, the one thing that
determines whether something is a member of the Set-B or Set-C, for
HTTP, is that 200 OK in response to a GET, hence why we need the 303.
This proposal appears to try and override that "rule" (fact) by saying
let the content of a representation define what is a member of Set-B or
Set-C, however the act of dereferencing itself is what determines
whether an identified thing is a member of Set-B, as Set-B is the set of
all things that can be dereferenced. Hence my confusion at this proposal.
Hope that makes sense, and that I've not totally misunderstood.
Best,
Jeni
On 28 Mar 2012, at 14:46, Nathan wrote:
Nathan wrote:
Jeni Tennison wrote:
# Details
In section 4.1, in place of the second paragraph and following list, substitute:
There are three ways to locate a URI documentation link in an HTTP response:
* using the Location: response header of a 303 See Other response
[httpbis-2], e.g.
303 See Other
Location: http://example.com/uri-documentation>
* using a Link: response header with link relation 'describedby' ([rfc5988],
[powder]), e.g.
200 OK
Link: <http://example.com/uri-documentation>; rel="describedby"
* using a ‘describedby’ ([powder]) relationship within the RDF graph created
by interpreting the content of a 200 response, eg:
200 OK
Content-Type: text/turtle
PREFIX :<http://www.iana.org/assignments/relation/>
<http://example.com> :describedby
<http://example.com/uri-documentation> ;
.
Seeking clarification,
Given some arbitrary thing and a description of that thing, let's say:
<http://example.org/uri> is described by <http://example.org/uri-documentation>
Previously we could GET /uri and either:
a) follow the value of the Location header in a 303 response to get to
/uri-documentation
b) follow the value of the Link header to get to /uri-documentation
With this proposal though we'd be able to say issue a GET to /uri with an
Accept header value of text/turtle, and the server could return back the
contents of /uri-documentation, with a status of 200 OK, and where the
text/turtle response contained:
PREFIX :<http://www.iana.org/assignments/relation/>
<http://example.com> :describedby <http://example.com/uri-documentation>
PREFIX :<http://www.iana.org/assignments/relation/>
<http://example.org/uri> :describedby <http://example.org/uri-documentation>
c+p error, apologies.
Is this correct?
TIA
