W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Change Proposals and FPWD Resolutions

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 9 Dec 2009 12:02:33 -0600
Message-ID: <643cc0270912091002g5f94fbam3ab80bdf94357e90@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Manu Sporny <msporny@digitalbazaar.com>, public-html@w3.org
On Wed, Dec 9, 2009 at 11:21 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> Shelley Powers wrote:
>>
>> On Wed, Dec 9, 2009 at 10:38 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>>>
>>> Shelley Powers wrote:
>>>>
>>>> There should be one clean straw poll vote: leave microdata in, or remove
>>>> it
>>>
>>> This is not intended to be a vote.  See:
>>>
>>> http://lists.w3.org/Archives/Public/public-html/2009Dec/0273.html
>>> http://lists.w3.org/Archives/Public/public-html/2009Dec/0245.html
>>>
>>> In particular:
>>>
>>> "We will not do any numerical counting all the votes. All we
>>> will look at is the objections and rationale presented"
>>>
>>> - Sam Ruby
>>>
>>
>> Then I would assume you're looking at the rationale given for whether
>> Microdata is left in the HTML5 spec, because there has been little or
>> no discussion about publishing Microdata as a separate specification.
>> Why? Because we haven't resolved the issue of whether Microdata will
>> remain in HTML5 or not.
>>
>> I don't equate support for Microdata in HTML5 as equivalent to support
>> for Microdata as a separate specification.
>>
>> Our change proposals should focus on specific, focused actions. When I
>> wrote the dt/dd change proposal, I focused on removing dt/dd from
>> figure and details, and since that left a gap, proposed an
>> alternative. This, even though I don't like details, I think it's
>> redundant functionality to what we have today, and I'm not
>> particularly overjoyed with figure.
>>
>> However, proposing removing or altering details and figure, in
>> addition to the dt/dd change, would have just muddied the change
>> proposal -- it would have merged multiple actions into one proposal,
>> making it difficult to determine if those who supported the proposal
>> did because dt/dd were removed from figure and details, or because
>> people agree with removing or modifying figure and details.
>>
>> What I did, instead, is start separate actions for both figure and
>> details, apart from the issue of dt/dd. This way people can express
>> support for or against removing dt/dd and creating a new element for
>> captioning in both, separate from the action for removing details, and
>> separate from how figure is handled. It may seem like a lot of extra
>> work for the group, a lot of extra discussion, but it's really a way
>> of cleanly separating actions for each change proposal.
>
> Commendable.  Clear.  Specific.
>
>> Returning to Microdata, those who may want Microdata pulled from the
>> HTML5 spec may not care if its published or pursued individually. But
>> some may care that it is actively pursued, because it generates
>> conflicted direction in the W3C. That's two separate things, though.
>> The first is, whether Microdata is removed or not. Then, if it is
>> removed, what to do with it.
>>
>> I really hope we encourage clarity and specificity of action with our
>> change proposals going forward.
>
> Manu's current proposal has clearly taken a different tact, but that doesn't
> necessarily make it any less commendable, clear, or specific.
>
> Manu, if you feel that you need to update your proposal to be any more clear
> or specific, I hereby encourage you to do so now.
>

I could wish that you hadn't re-phrased this so that makes it seem as
I'm being overly critical of Manu's proposal. Manu's work is good, and
if people believe the best course for Microdata is to split it from
HTML5 AND publish it separately, fine. But this is now the only
proposal available to us. That or keep Microdata in HTML5.

The point I tried to make was that change proposals that combine
multiple, and not necessarily consistent or compatible changes into
one proposal can make it difficult to ascertain exactly what people do
or don't support. However, from your response Sam, evidently, the
chairs don't see this as a problem, or something to be discouraged. I
don't agree, but all I can do is ensure my own change proposals are
precise and specific.

>
> - Sam Ruby
>

Shelley
Received on Wednesday, 9 December 2009 18:03:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC