Re: ISSUE-92 Change Proposal

On Apr 12, 2010, at 7:57 PM, Shelley Powers wrote:

> On Mon, Apr 12, 2010 at 7:40 PM, Tab Atkins Jr.  
> <jackalmage@gmail.com> wrote:
>> On Mon, Apr 12, 2010 at 5:27 PM, Tab Atkins Jr.  
>> <jackalmage@gmail.com> wrote:
>>> I find nothing objectionable in this Change Proposal, and agree that
>>> the example table used in the spec is somewhat contrived and
>>> unrealistic.  The example table given in this Change Proposal seems
>>> more realistic, exhibiting useful complexity without being
>>> overwhelming.
>>
>> On second review, I have to retract my statement that there is
>> "nothing objectionable".  The table itself is generally acceptable as
>> an example of a table.
>>
>> However, I had skipped over the part where the @summary attribute is
>> reintroduced, and given an explanatory paragraph.  That is not
>> relevant to the Issue at hand, and given the current state of the
>> @summary attribute, should be removed.  If @summary is later
>> reintroduced as a valid attribute in HTML, the example may be  
>> amended.
>
> Rather than address this one before @summary, I believe the co-chairs
> should resolve the issues related to @summary, first, and then we can
> revisit this change proposal.
>
> Co-chairs?

Here are some possibilities:

1) Adjust the current Change Proposal to be agnostic about the future  
@summary change, and then we can work it through the process without  
waiting for ISSUE-32. Then revisit whether to highlight @summary in  
the example after ISSUE-32 is settled. It tentatively sounds like that  
is more likely to get consensus in the short term.

2) Process the current Change Proposal as-is right away. It seems like  
at least Tab is objecting to that option, so we'd need a call for  
counter-proposals.

3) Keep this proposal on hold until ISSUE-32 is settled. Then either  
revise it, or process it as is, depending on ISSUE-32 resolution.

I haven't consulted with my co-chairs, but personally speaking, option  
#3 is my least favorite. I prefer for things to move forward  
independently than to be blocked indefinitely with no clear deadline.  
The quicker we move through issues the closer we get to a quality spec  
that can move closer to Last Call. So I'll be real happy if we can  
work this one out sooner rather than later.

Regards,
Maciej

Received on Tuesday, 13 April 2010 04:18:49 UTC