- From: Cameron Jones <cmhjones@gmail.com>
- Date: Fri, 11 May 2012 23:04:35 +0100
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: public-html@w3.org
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