Working Group Decision on ISSUE-184 Add a data element

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic as there
were no additional responses in the poll itself.

*** Question before the Working Group ***

There is a basic disagreement in the group as to where and which
specification should define a type system for the <data> and <output>
elements.  This is the sole remaining issue necessary to resolve ISSUE
184.  We have two distinct proposals for this question, and a straw poll
for objections.

http://www.w3.org/html/wg/tracker/issues/184
http://www.w3.org/wiki/User:Cjones/ISSUE-184
http://www.w3.org/wiki/User:Tantekelik/data_element
http://www.w3.org/2002/09/wbs/40318/issue-184-objection-poll/results

== Uncontested parts of the proposals:

Previously, we found that we had consensus on the addition of the data
element itself:

http://lists.w3.org/Archives/Public/public-html/2012Apr/0026.html

As such, this decision focuses exclusively on whether or not we should
add a type system.

== Objections to the proposal that adds a data element without a type 
system:

http://www.w3.org/wiki/User:Tantekelik/data_element

Without clearly stated objections in the poll itself or even in the
proposal itself, an attempt was made to infer objections based on the
presumption that one or more of the benefits attributed to the proposal
would not be obtained if the proposal were not adopted.

   While this text could be parsable it is highly ambiguous and can not
   be used to definitely acquire the value or type of data.

Not a single example was given to support this claim.  As such, this
assertion was given little weight.

   there are numerous types of data represented by the <data> element and
   there is significant scope for overlap within text-encodings. This
   leaves the problem of what the value represents and how to use it.

   The addition of a type attribute for data values introduces a set of
   constraints over the valid values that the element may represent. This
   provides the ability for the value to be restricted to a known data
   type which can be enforced within the HTML client. This provides the
   benefit that data values can be used programatically in a safe manner
   where data can be accessed without having to handle invalid values or
   manipulate encodings.

Even if we accept the premise, without a description of what the
constraints would be and what the actions required of the User Agent
should the data provided not conform to the constraints, it is entirely
unclear how the purported benefit would be provided.  In fact, one of
the stated benefits is that the data can be accessed using simple DOM
functions.  Certainly in legacy user agents which do not implement this
proposal, those functions would return the values as provided, whether
or not they would be considered valid.  Again, this was given little
weight.

   this process can be enhanced to allow the client to render the value
   to a format defined through the type discriminator and the element's
   resolved locale

Perhaps the converse of this (without the type attribute the process
can't be enhanced) /could/ be an objection, but again no evidence was
provided that this is the case, or that there is any existing users who
would make use of this or any implementors willing to provide this
function.  At most, this would constitute a weak objection.

   Data is annotated with specific known types

Noting that the annotation is optional (details #3), it is unclear how
this is an objection.  To have been considered an objection, use cases
would have needed to be provided that could be addressed if this
proposal were adopted, but failing that would go unfulfilled.

   Data can be accessed using simple DOM functions

This applies to both proposals, so was not treated as an objection.

   Consumers are protected from invalid values or needing to manipulate
   text encodings

Lacking any evidence that any consumers want this protection, or any
details on how this protection would be provided, this was not
considered any further.

   Allows for automatic user agent substitution of formatting of data
   values with client-side localization

Again, lack of evidence of user demand and lack of specification of how
it might be provided should there be a demand made this objection weak
at best.

   The <output> element may perform automatic transliteration of data
   type values from <input> values with restriction and validation

In addition to the comments made above, we found the "may" to be
troubling.  Unless this is specified completely and implemented
interoperably, it is entirely unclear how authors could depend on this
functionality.

   Allows for greater specificity and control over the denominations of
   date and time information currently afforded to the <time> element and
   its proposed extensions

Again, lack of provided use cases and lack of specificity made it
difficult to consider any objection to not providing this feature as
anything but weak.

Overall, we found all of the objections to NOT providing a type system
to be weak.

== Objections to the proposal that adds a data element with a type
system:

http://www.w3.org/wiki/User:Cjones/ISSUE-184

Objections from the original (Tantek) proposal:

   Counter-proposal is unimplementable

This is a clearly strong objection.  Examples of parts of the "type
system" proposal that lack sufficient detail to be implemented
interoperably: details sections 4 and 6.

As this is already stronger than the objections provided to the original
proposal, there is no need to evaluate this proposal further.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the <data> element
without a type system change proposal:

    http://www.w3.org/wiki/User:Tantekelik/data_element

Of the Change Proposals before us, this one has drawn the weaker
objections.

== Next Steps ==

Since the prevailing Change Proposal does not call for a spec change, no
further action is required.  ISSUE 184 will now be closed.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.

== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* A specification, with sufficient detail to be implemented
   interoperably, and identification of a substantial body of use
   cases that are not addressable unless that specification is adopted.

Additionally, reopen requests are encouraged to address as many as 
possible of the remaining objections.  In particular, the co-chairs 
would be interested in proposals which address the stated 
"authorability" and "error prone" objections.

- Sam Ruby

Received on Tuesday, 17 July 2012 19:25:26 UTC