W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: ISSUE-81: representation-vs-resource - Chairs Solicit Proposals

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sat, 16 Jan 2010 23:00:36 -0800
Cc: HTMLWG WG <public-html@w3.org>
Message-Id: <8EB35C81-9C15-4AC9-A646-D00BE88274DF@gbiv.com>
To: Maciej Stachowiak <mjs@apple.com>
On Jan 12, 2010, at 6:32 PM, Maciej Stachowiak wrote:
> On Jan 6, 2010, at 3:59 PM, Roy T. Fielding wrote:
>> On Dec 8, 2009, at 7:06 PM, Maciej Stachowiak wrote:
>> 
>>> This issue has been open for two and a half months, and the only concrete proposal we have at this point is in the draft.  At this time the chairs would like to solicit volunteers to write Change Proposals.
>>> 
>>> http://www.w3.org/html/wg/tracker/issues/81
>>> http://dev.w3.org/html5/decision-policy/decision-policy.html#escalation
>>> 
>>> If no Change Proposals are written by January 16, 2010 this issue will be closed without prejudice. (That's an extra 8 days over the usual one month deadline to account for the winter holidays.)
>> 
>> It is nearly impossible to write a change proposal based on a
>> moving target to fix a pervasive misuse of terms in the
>> current draft.  I could write the changes, but that would
>> effectively be forking HTML5 or replacing the current editor.
>> 
>> I would like this issue to be postponed until after the changes
>> already proposed have been committed.
>> 
> 
> The chairs discussed your comments on this issue today. We understand that it can be difficult to write a proper change proposal for an intrusive and wide-ranging change against a moving target. On the other hand, we don't want to let this issue remain open indefinitely, and it doesn't seem like there will be any obvious point when changes have stopped. We feel the following would be appropriate and sufficient for the Details section of a Change Proposal on this issue:
> 
> - Identify a specific revision of the HTML5 draft as a baseline.
> - Describe in detail how to make the changes against that particular version.
> - Indicate that analogous changes should be made if any of the spec changes.
> 
> It's possible that some of the text surrounding the term usage will change over time, but we would still consider the Change Proposal valid. If you'd like to volunteer to write a Change Proposal on that basis, please let us know, and indicate what kind of deadline would be appropriate.

A deadline six months from now would be appropriate.  I see no evidence
to suggest that the spec will be ready for progression before then,
nor is there any basis for insisting that *this* issue be handled
before all of the others that have yet to be even called.

My plate is full until after the IETF meeting in March, immediately
after which I expect to go on paternity leave.

> Alternately, we can just allow this issue to be closed without prejudice, and it would still be an option to reopen the issue at a future time if someone actually submits a completed Change Proposal. That could be months from now when the spec may be more settled, if we haven't hit Last Call by then.

That isn't going to change my formal objection.  All it does is hide
the issue from view.

> Either of those approaches would be ok with us. But we do not want to have the issue remain a blocker without a clear and reasonable deadline.

The clear and reasonable deadline I am asking for is that, when you
have assigned a deadline for the last blocker issue, then assign
the same deadline for this one.  What's the harm in that?

....Roy
Received on Sunday, 17 January 2010 07:01:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC