- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 15 May 2012 02:05:07 -0700
- To: Cameron Jones <cmhjones@gmail.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
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