Re: Chair review of the issue-184 change proposals

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

Received on Friday, 4 May 2012 22:28:22 UTC