W3C home > Mailing lists > Public > public-awwsw@w3.org > February 2011

How to track new TAG work on 303 vs. 200 issue raised by Harry

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 21 Feb 2011 11:56:11 -0500
Message-ID: <AANLkTi=Ls0zypXZnv2w4301nGfD9fuTfEv=-jrhJka4x@mail.gmail.com>
To: AWWSW TF <public-awwsw@w3.org>, Harry Halpin <hhalpin@w3.org>
As I reported earlier, I'd like to help bring about a consensus document
about the httpRange-14 resolution and its consequences.  I have a
TAG action open on this, which is to figure out what TAG issue to track
this work under.


I have two purposes in mind for the document.  One is to describe what
was decided - why it was done, how it works, and what benefits one
gets if it's followed.  The other is to document and if possible
address recently raised concerns, with Harry's message
http://lists.w3.org/Archives/Public/public-awwsw/2011Jan/0021.html as
a launching point.  This may end up being two or more documents.

Here are some tracking options:

Closed issue:
  14 httpRange  (using this was Henry's suggestion)

Open issues:
  39 rdfURIMeaning http://www.w3.org/2001/tag/group/track/issues/39
  57 HttpRedirections (mainly about interaction of 30x and semweb)
  62 UniformAccessToMetadata (mainly about Link: and .well-known)
  63 metadataArchitecture (mostly about preventing bad interactions
       and inconsistent practice)

Or a new issue. (Tracker doesn't allow you to associate actions
and comments with products.)

I don't consider any of the open issues to be appropriate.  57 and 62
are too narrow, and the problem cuts across both 39 and 63.

I don't consider issue 14 to be appropriate, even though the design
space is the same.  It was closed to the satisfaction of the TAG at
the time, and has way too much baggage associated with it.  The new
work should be described under the pain point (what problem retracting
the resolution would be the solution to), not under the design space.

For your reference, here is what I think the question to which the
httpRange-14 resolution was the (partial) answer:

    How to (1) refer to the Web-accessible information resource at a
    URI, and (2) provide a URI for a thing given a description of it,
    given that each dereferenceable URI can be used for only one of
    these two purposes?

The resolution was fine given this as the question. My description
of Harry's problem is something this:

    Linked-description-based URI definition is too hard, given hash
    and 303 URIs as the only agreed ways to do it.

(I added the funny adjective 'linked' to rule out non-nose-followable

Obviously liberating 200s would be one solution, and perhaps the
only one, but the issue description shouldn't presuppose any
particular solution.

I'd be happy with more specific or general versions if Harry or others prefer,
such as 'RDF-based' instead of 'description-based', or some word other
than 'definition' (I like 'binding' but I know that doesn't do much
for most people), or even

    Hash and 303 don't work for associating descriptions with URIs.

or we could phrase it like a question, like most TAG issues

   What is an easily deployed way to associate a URI with a
   description of its intended referent?

My inclination is to propose a new TAG issue with a general
description like the above, and track the new work under it.  (We
would need a short name too, and a longer description. The longer
description would cite Harry's email.)

Since the people on this list have been involved in the discussion,
I'm asking your advice in defining and describing the new issue in the
next couple of days, or in talking me into using an existing issue
for tracking.

Received on Monday, 21 February 2011 17:04:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:09 UTC