Re: Chair review of the issue-184 change proposals

On Fri, May 4, 2012 at 11:27 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 03/27/2012 07:08 AM, Sam Ruby wrote:
>>
>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-184
>>
>> "Add a data element"
>>
>> ----
>>
>> Change Proposals:
>>
>> http://www.w3.org/wiki/User:Tantekelik/data_element
>> http://www.w3.org/wiki/User:Cjones/ISSUE-184
>>
>> Both Change Proposals for ISSUE-184 agree on adding a <data> element and
>> most of its details. In fact, the latter proposal explicitly includes
>> all of the Details from the former by reference.
>>
>> The latter proposal differs in that it adds a "type" attribute to the
>> <data> and <output> elements.
>>
>> The chairs plan to take a similar approach to what we did with 183 and
>> just call for consensus on the addition of <date>. This would obviate
>> the need to review Tantek's Change Proposal and would allow much of
>> Cameron's Change Proposal to be removed.
>>
>> The complication in this case is that no one has made an attempt to
>> counter Cameron's additional changes to <data> (and <output>). As
>> Cameron's Change Proposal is lacking sufficient details at this point,
>> it is not necessary to explicitly counter it until and unless it is
>> improved.
>>
>> =======================================================================
>>
>> Review of the "Enhance the <data> element with a type system" Proposal:
>>
>> - The changes also included in Tantek's Change Proposal are likely to be
>> adopted by consensus, so there is no need to describe or justify them.
>> What remained would be a Change Proposal solely about the addition of a
>> type attribute to <data> and <output>.
>>
>> - The Details as currently written seem insufficient, and the Change
>> Proposal will likely be rejected for insufficient Details if not revised:
>> - Items 2 and 3 describe a type attribute added to <data> and <output>
>> and the valid values for this attribute, but its not specified whether
>> it is valid to omit the type attribute for either or both of these
>> elements. Also, would types other than the standard enumerated values be
>> valid? These are important points to disambiguate.
>> - Item 4 in the Details says "Define the implementation rendering
>> algorithm for <data> and <output> elements without content as the
>> substitution of the value attribute with the application of style-based
>> formatting rules", this does not seem specific enough to apply
>> unambiguously to the spec.
>>
>> - The Rationale could be significantly improved, and at least one part
>> is so lacking that the Change Proposal is unlikely to succeed unless it
>> is improved:
>> - Justification of material also in Tantek's proposal is likely no
>> longer necessary.
>> - The Rationale says that a "type" attribute would allow consumers of
>> machine-readable data held in <data> elements to determine how to turn
>> the value into machine-readable data. However, this doesn't seem to be
>> backed up by the Details section; no parsing rules or format definitions
>> for the different types are specified, so it is unclear how a type would
>> make parsing easier. Perhaps such rules are intended; if so they should
>> be added to Details.
>> - The Rationale doesn't seem to identify a clear use case for adding a
>> type attribute to <output>; it mentions that UAs could do certain things
>> in response to type attributes, but does not identify why this would be
>> desirable.
>
>
> If these problems are not addressed by Fri May 11th, the chairs will treat
> this proposal as withdrawn.
>
> - Sam Ruby

I have updated the proposal with the changes from the review.

Thanks,
Cameron Jones

Received on Friday, 11 May 2012 22:05:05 UTC