Jeni Tennison wrote:
Nathan,
On 28 Mar 2012, at 16:07, Nathan wrote:
Jeni Tennison wrote:
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.
Then it would return those things. I think that you may have leapt to the
conclusion that /uri *always* returns the same as /uri-documentation. There's
nothing to my knowledge that says that, indeed given that you can have several
:describedby links it would be impossible.
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?
Under the proposal, the server would return the JPEG with a 200 OK for a GET on /uri. http://example.org/uri-documentation would return a description of the JPEG in some machine-readable format.
Previously I asked:
"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 you replied "Yes, that's correct."
The above is exactly the same, so I'll ask again:
With this proposal can a server can return the contents of
/uri-documentation with a status of 200 OK for a GET on /uri?
If the answers yes, then it must be yes for my previous "JPEG of a
monkey" example (universality), if the answer is no then how does this
proposal work? Apologies for my confusion.
Best,
Nathan
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).
I don't really understand what you think it needs to say I'm afraid.
Question B:
How would conneg work, and what would the presence of a Content-Location
response header mean? Would HTTPBis need to be updated?
I can't see any way in which any of that would work differently from currently.
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")?
The proposal says that applications can draw no conclusions from information at
the transfer protocol level about /uri. In particular, it can't tell whether
the representation that is returned with /uri is *the content* of /uri or *the
description* of /uri. Further information about /uri (eg that it is a
foaf:Person) may help the application work out that the representation was *a
description*.
However, an application can draw conclusions about /uri-documentation, assuming
it gives a 2XX response, because it has been retrieved as the result of
following a :describedby link (or if it were the target of a 303 redirection).
The application can tell that the representation from /uri-documentation is
*the content* of /uri-documentation and *the description* of /uri.
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?
Because /uri-documentation was reached through a :describedby link. This extra
information allows the application to draw the conclusion that the
representation from /uri-documentation is *the content* of /uri-documentation.
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.
The "fact" that a 200 OK determines whether something is a member of Set-A or
Set-B is a design choice made by httpRange-14, not a fundamental truth of the universe.
The proposal makes a different design choice, in saying that you need more than just a
200 OK response to say, beyond all doubt, that a URI refers to something that is member
of Set-B.
Cheers,
Jeni
