Nathan, The server *can* return the same content from the /uri URI and from the /uri-documentation URI, but it does not have to, and it wouldn't be sensible to do so for an image. Your first question asked if the server could return the same content, your second asked if it must.
Jeni -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Nathan <[email protected]> wrote: 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
