Yet another workaround for definition discovery

Henry S. Thompson
19 Sep 2011

1. No introduction

See Providing and discovering definitions of URIs

2. What everyone wants

Is a 200 OK response with a single retrieval, with a minimum of hassle. Including hassle from the standards enforcement police. How can we legitimately give e.g. Ian Davis what he wants without breaking the 'official' story, and without exposing ourselves to the kind of contradiction which e.g. the following exposes us to:

 <> doc:versionOf

3. We're so close

303 See other has a satisfying semantics, for the standards police, but requires two fetches. Why don't we just allow clients to pre-empt that second fetch? This isn't a new idea, but just maybe I have a new story which would make it palatable to all concerned. So, instead of e.g. the MGET proposal, what I'm proposing is a new request header, which would be effectively a meta-level form of Accept. Let's call it (tip of the hat to BCS), Accept-Reflect, or (being too painfully explicit) Accept-See-Other. In either case the allowed values are just Yes, No and 303, with the default being 303.

The simple (simplistic, see below) gloss is that this header means that you want the server to do the 303 work for you, i.e. to interpret that header to mean "If you were going to send me a 303 + Location: foo, please don't, just go ahead and treat this as a GET of foo".

4. But what about the example?

So that's slightly too simple a story. What Accept-See-Other: Yes really means is that I actually prefer the auto-303 behaviour if you have a choice. Thus the other name: the new header means not just "I'll take a definition if that's all you have", rather it means "I want a definition, regardless of whether you have (a webarch:representation of) das ding an sich or not.

5. Analysis by cases

We imagine three classes of servers going forward:

(In the table below, there is no column for "no repr, no defn", because that column is always 404 Not Found)

Server supports new header Server doesn't support new header, httpRange-14 compliant Server doesn't support new header, not httpRange-14 compliant
Have only repr Have only defn Have both Have only repr Have only defn Have both Have only repr Have only defn Have both
GET + Accept-Reflect: 303 200 + repr 303 + Loc: defn_loc 200 + repr 200 + repr 303 + Loc: defn_loc 200 + repr 200 + repr 200 + defn could be either
GET + Accept-Reflect: Yes 404 200 + defn 200 + defn 200 + repr 303 + Loc: defn_loc 200 + repr 200 + repr 200 + defn could be either
GET + Accept-Reflect: No 200 + repr 404 200 + repr 200 + repr 303 + Loc: defn_loc 200 + repr 200 + repr 200 + defn could be either

The first row is also the row for a GET without the new header at all, i.e. it's important that it reconstructs the current situation, and the fact that the first three cells are the same as the middle three confirms that that's the case.

The third class of servers are ones which serve definitions with 200 today, either intentionally because they believe the httpRange-14 decision is wrong, or necessarily because their users can't or don't know how to initiate the redirect, and can't or won't change to support the new header.

The coloured cells are of particular significance:

Ian Davis should be happy: if his tools (alleged to always want definitions) and server (always deliver definitions anyway) implement the new header, he gets exactly what he wants.
Ian Davis should be moderately happy: when his tools encounter a non-compliant server which only has definitions, or someone else's not-header-using GET hits his server, the result is slower, but correct
A new-header-using tool that says it doesn't want reflection gets it anyway from a standard server. Not too worried about this, as this row is not going to get used by either community, I suspect.
These are the problematic cases. This is because a with-header GET expects 200 to mean "here's your definition", but in the pink cases it isn't, it's a representation. I'm going to argue we can live with that, because e.g. Ian Davis claims he has no such cases, and the retrieved Content-Type will almost always disambiguate. But not always, e.g. if you are trying to assert authorship of a page of RDF-XML.
These are broken now, and will continue to be broken since as defined they won't change.
How these stand depends on which of repr or defn the server provides when both are available.

6. Conclusion

How bad are the pink cases? Otherwise I like this a lot. . . The bottom row will only every arise for really smart apps which know that they are dealing with compliant servers wrt documents in sub-column 3, and that case wins. The top row, which will be 99.99999% of all GETs for the foreseeable future, is an improvement on the status quo. The middle row is a huge win when both client and server step up, and either rare (the middle group) or no worse than any other proposal (because the right-hand column is the servers that won't implement any change.