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. > 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 -- Jeni Tennison http://www.jenitennison.com
