Re: Chair review of the issue-184 change proposals

Thank you for the update. The Details are still not clear enough to unambiguously apply. Trying to imagine myself in the role of editor, I do not believe I would be able to determine the correct edits to make to the spec based on points 4-6. Points 1-3 are terse and oddly worded but I think I know what they mean. My co-chairs were also unable to understand points 4-6 enough to envision a specific edit. This could be a failure of understanding on our parts, but we believe most editors would have the same problem without further clarification of points 4-6.

Regards,
Maciej

On May 11, 2012, at 3:04 PM, Cameron Jones <cmhjones@gmail.com> wrote:

> 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 Tuesday, 15 May 2012 09:06:01 UTC