TagIssue57Responses

From W3C Wiki
Revision as of 11:22, 30 March 2012 by Jrees (Talk | contribs)

Jump to: navigation, search

On 29 Feb 2012, JAR (Jonathan Rees) issued a call for proposals to address TAG ISSUE-57. This page summarizes the responses received.

Several proposals are included that do not use the change proposal template. I may have missed some.

Most proposals are designated by the name of the sender of the message containing the proposal. Some of those are group efforts.

Almost all proposals received so far amount to either changes in the interpretation of 200 responses (retrievals), or reinforcement of the status quo. The key question is:

  • Is a retrieval (200) response to be interpreted as content of the identified resource, or not?

with the implication, usually, that under common circumstances, if the representation looks like or contains a description, it can be interpreted as a description.

The proposals differ mainly in how this question is answered.

Always-content proposals

Each of these proposals says that a representation is content (an instance) of the identified resource. Sometimes they make the weaker statement that such a representation of an information resource, but this has almost always been understood as implying the former.

These proposals do not really address ISSUE-57. In effect they try to dismiss ISSUE-57 by saying people should be convinced to either use hash URIs or suffer with 303's defects.

A proposal for a new HTTP status code, which is of this kind, came up on the LOD list, but has not been turned into a change proposal yet. Other proposals of this kind have been made in the past but have not been promoted during the CFP.

No change

Given here

The key question is not answered as httpRange-14(a) is written, but most people take it to mean that the retrieved representation is content.

Retrieved representations are always content (instances)

Jonathan Rees wrote this message which does not address ISSUE-57 but suggests strengthening httpRange-14(a) to say that retrieved representations are instances (content), or else retracting httpRange-14(a), see previous.

(It is not written in change proposal form as it does not address ISSUE-57.)

Use hash or 303

Mo McRoberts submitted this proposal on 1 March. This proposal takes on a broader scope than just ISSUE-57.

A follow-up from the author expresses doubt of the proposition that hash URIs are unacceptable.

New HTTP status code

Email from Kjetil Kjernsmo on 28 March suggesting a new 2xx status code.

Content opt-out proposals

These proposals say that the agreement as in "always-content" generally holds, unless some special property holds of the HTTP response (headers or content).

Proposal 25

Email from Tim Berners-Lee which links to

The retrieved representation is non-content if the Document: header is present (if the response "opts out" of the content assumption).

In the opt-out case, the representation may be content of the resource, but the receiver cannot assume so without some other signal.

Look for contradiction

Email from Norman Gray on LOD list - not in change proposal form.

This says that to opt out of the representation being content of the identified resource, it says something inconsistent with this being the case.

Content opt-in proposals

These proposals have in common that retrieved representations are not assumed to be content of the resource. That is, a compliant server can deliver a representation that is not content of the resource. To deduce that a representation is content (i.e. to opt in) additional information would be needed, or assumptions not justified by the proposal itself.

Retract httpRange-14(a)

No consensus agreement that is; allow users to figure out solutions for themselves. Given here.

This does not directly address ISSUE-57 or the key question, and it presents some risk. It leaves open the possibility that ISSUE-57 might be addressed somehow in the future.

SHOULD not MUST

A bit stronger than a plain retraction, Jonathan Rees proposes here that interpreting a response as content is good practice, while acknowledging that practices may vary so you have to be careful.

This is the only one of the opt-in proposals that specifies a way to opt in.

(Not in change proposal form as it does not address ISSUE-57)

"No longer implies"

Proposal email from Jeni Tennison; long thread on public-lod list with many interesting responses starts here.

"A 200 response to a probe URI no longer by itself implies that the probe URI identifies an information resource"

A limited opt-in mechanism is given, but it is only available in very special circumstances.

"Always a description"

Proposal email from Tore Eriksson. I think what's being said is that what's retrieved is always either description or uninterpreted, and never to be seen as content (without some further signal, not specified).

Quote from previous version (update needed): "A representation retrieved from a HTTP URI will never [unless stated] be equivalent to what the URI denotes (the resource), but will always be a description (of the state) of the resource"

"Middle ground"

Email from David Booth

This proposal appears to include httpRange-14(a), but the words used in the statement are redefined in the document. So although the same words are used, the statement means something quite different.

Don't use http:

Christopher Gutteridge expressed some ideas on a blog post. Key quote: "I think it’s daft to use the same protocol to unqiuely identify real-world objects AND documents on the web. I have to explain this again and again to each person learning RDF, and it won’t take off if people can’t figure it out for themselves, like HTML, JSON, XML etc."

This has not been turned into a change proposal as of 29 March.

Comments on the baseline document

There have also been some comments on the baseline document that was prepared in preparation for the call for change proposals. These comments do not address ISSUE-57.

Some of the issues raised regarding the document are tabulated at UddpIssues.

JAR does not intend to work further on the baseline until the TAG has decided on a strategy for discharging ISSUE-57.