Chair review of the issue-184 change proposals

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.

- Sam Ruby

Received on Tuesday, 27 March 2012 11:09:12 UTC