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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 20 Jan 2010 18:52:50 -0800
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Sam Ruby <rubys@intertwingly.net>, Larry Masinter <masinter@adobe.com>, "julian.reschke@gmx.de" <julian.reschke@gmx.de>, HTMLWG WG <public-html@w3.org>
Message-id: <A632360C-CF36-40D5-89CB-093040548D16@apple.com>
To: Paul Cotton <Paul.Cotton@microsoft.com>

On Jan 19, 2010, at 1:35 PM, Paul Cotton wrote:

>> I think you could close the action even before the meeting if you're satisfied that it was performed, since it doesn't really merit discussion.
> 
> Since Roy is unavailable to work on this Issue, the Chairs have decided to extend this solicitation for one week to January 23.  This will permit anyone else that is interested in this issue an opportunity to let the Chairs know if they are interested in drafting a proposal to resolve Issue-81.
> 
> If no such offer or change proposal is forthcoming then Issue-81 will be closed without prejudice at the Thu Jan 28 WG meeting.

I have updated the deadline on the status page:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-081

Anyone who is willing and able to do the work on this issue should volunteer ASAP.

Regards,
Maciej


> 
> /paulc
> 
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
> 
> 
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Roy T. Fielding
> Sent: Tuesday, January 19, 2010 2:23 AM
> To: Maciej Stachowiak
> Cc: Sam Ruby; Larry Masinter; julian.reschke@gmx.de; HTMLWG WG
> Subject: Re: ISSUE-81: representation-vs-resource - Chairs Solicit Proposals
> 
> On Jan 18, 2010, at 4:29 PM, Maciej Stachowiak wrote:
> 
>> 
>> On Jan 18, 2010, at 2:28 PM, Sam Ruby wrote:
>> 
>>> Maciej Stachowiak wrote:
>>>>> The alternative which is clearly within the chair's discretion is:
>>>>> " With prior permission from the chairs, a high-level prose
>>>>> description of the changes to be made."
>>>>> Given Roy's rationale, I think allowing a change proposal with a
>>>>> high-level prose descriptions of the changes to be made would be
>>>>> useful.
>>>> While we have not discussed the possibility of just a high-level
>>>> prose description without showing any detail, my own feeling is that
>>>> it would leave too much room for misinterpretation.
>>> 
>>> I think we should seriously consider this.
>> 
>> I'd like to hear whether Roy has a problem with both of the alternatives I listed before we consider watering down the requirements further. Just to repeat them for the record:
>> 
>> 1) Write the changes against a specific CVS version number of the spec. If the Change Proposal succeeds, then we will expect the changes to be applied properly to any changes as well.
>> 2) Write clear definitions of all affected terms, possibly in the form of suggested edits to the terminology section, and demonstrate correct usage of the terms by suggesting specific edits to one or two representative sections.
>> 
>> In particular, I don't think #2 is materially more work than a "high-level prose description", but it seems much less likely to lead to debates over how to interpret the Change Proposal. I'd like to hear from Roy whether he considers it acceptable, and if not, is there anything else that would work for him.
> 
> I don't have time to do any work on this for the next four months.
> That was the point of my initial request that this issue be
> postponed.
> 
> Honestly, unless you can prove to ME that there is a substantial
> burden being imposed upon *someone* by reordering the entirely
> random order that chairs have decided to call for consensus, then
> it should be obvious that *MY* constraints are more important
> than whatever you personally think the procedure should be.
> Otherwise, you are just railroading a particular conclusion.
> 
> If someone else does the work before I have time, that's fine.
> If we run out of issues to call, then that's when you
> should impose a one-month deadline (because that is when this
> issue would be in the critical path).  Until then, this issue
> is only a spec-progress blocker, not an implementation blocker,
> and I really don't care to participate in this discussion
> because I don't have any free time to do so.
> 
> ....Roy
> 
> 
Received on Thursday, 21 January 2010 02:53:23 UTC

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