Re: Chair review of the issue-184 change proposals

Thanks again for the feedback.

Regretfully i was unable to attend the F2F this month, it would have
been a great opportunity to discuss the issue and i believe we would
have achieved greater understanding of the overall problem domain.

Regarding the F2F minutes, there are a few inaccuracies i would like
to correct.

There was a CFC not on the inclusion of the <time> element, but on the
extensions to the date/time microsyntax. As the microsyntax is equally
applicable to <data> as to <time> there is no contention between this
functional enhancement and as such there was unanimous consensus on
its practical benefits to both proposals.

There has additionally been a CFC on the addition of the <data>
element which has also been resolved by consensus. There has been no
objection to the necessity nor approach of the <data> element and it's
purpose.

The open question, which was the source of the issues, is whether the
addition of <data> with a suitable type discriminator renders the
<time> element obsolete.

If there were no overlap in functionality between <time> and <data> i
would have no objection to punting the feature to HTML.next as was
suggested in the F2F. However, the concern is that if <time> will be
rendered obsolete then it is irresponsible for it to be included
within HTML5 and recommended for use within an environment which will
induce a legacy of code as encumbrance on future applications while
providing limited immediate gain.

The use case supporting the inclusion of <time> is the ability to
markup dates and times within documents. While this represents a valid
feature for authors to declare, the further use cases of how this
information is to be used and interfaced remains elusive.
Specifically, how will the date/time information be represented to the
user? This is a use case which has been investigated and developed
within the proposal for a type system for <data> and addresses this
not only for date and time information, but also for the other
datatypes which are explicitly defined within the Unicode CLDR. If
<time> is to be retained within HTML5 i believe it should at least
attempt to provide some indication as to how this use case will be
satisfied. Alternatively, if the implementation of <time> can be shown
to be immediately or eventually divergent from <data> then this would
also address the concerns over functional duplication and future
requirements.

The proposal for a type system as it currently stands requires some
more work to address the items highlighted within the review. I will
address these this week with specific attention to improving clarity
and coherence of both the rationale and the details. In the mean time,
if the issue can advance forward through the development of greater
understanding of the problem domain within list discussions, i believe
this will lead to an outcome sooner especially if some of the points i
am raising have not been communicated effectively.

Thanks,
Cameron Jones

On Tue, May 15, 2012 at 10:05 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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 21:24:15 UTC