Chair Review of the Change Proposals for issue 179

Both proposals are well formed in that they have the required sections.
This therefore is a review of the content.

===================================================================

http://www.w3.org/html/wg/wiki/ChangeProposals/av_param

Rationale starts by pointing out that HTML4 had a mechanism that was
used for this, and therefore "to maintain continuity" HTML5 should also.

This rationale is weak given that it doesn't cite actual usage.
Furthermore as this proposal isn't exactly what HTML4 provided,
supporting evidence that what is proposed would be something that people
would be willing to adopt would be helpful here.

The Change Proposal says that <param> would be added so that user agent
implementors could implement custom processing of particular parameters,
but it provides no evidence that any user agent vendor wishes to do so,
rather than standardizing any specific such parameters, even for the
UPnP use case.

The rationale then asserts that "it is not possible to a priori define
specific attributes to carry" UPnP attributes.  The counter proposal
proposes a way to do this.  Unless rebutted, that would make this
argument invalid.

In addition, the Change Proposal does not define, explain, or provide
links to information about UPnP or ContentDirectoryService (CDS),
thereby making it impossible for anyone to evaluate the validity of the
use case or check the claimed requirements.  Use cases need to provide
enough supporting info to enable it to be verified independently.

Remainder of Rationale (primarily eliminating other alternatives) looks
fine.

Details are complete.

Positive effects lack supporting evidence.  In particular, if the
proposal is going to make statements about accessibility, some
supporting evidence would be helpful.

As this proposal has identified no use cases, no users, and no
implementors, the chairs have decided that we will not proceed to a
survey until or one or more of these problems with the first proposal is
addressed.  If this is not done, we will decide in favor of the "no
change" change proposal instead.

===================================================================

http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change

As stated above, no changes are needed at this time.  If however, the
av_param proposal is updated acceptably, this proposal will need
substantial rework, primarily to address the data which is currently
missing from the other proposal.

As stated above, the mapping for UPnP seems plausible and unrebutted.

The enumeration of alternatives list data-* and x-* attributes.  The
original change proposal suggests why these are not appropriate, and
this counter proposal provides no data challenging that assessment.

It is not clear why extension specifications and data element are
listed.  Yes, there may or may not be other ways to solve this use case
(once provided), but what we are looking for in alternate or counter
proposals is an fully fleshed out and viable proposal that somebody is
willing to champion and pursue.

The entire section on Principle Approach lacks supporting evidence.  It
jumps directly from "there is no [current] requirement" directly to "it
is not possible".  Should the original proposal be updated to provide
use cases, and as the original proposal provides a mechanism, then this
assertion that "it is impossible" will not be given any weight.

The positive effects states that something that nobody is proposing (a
child to the source element) would be problematic.  There is no need to
include such a statement in the proposal.  It further states that adding
such a broken feature would be necessary "to be fully consistent".  No
support is provided for this statement is not supported.  If there is a
desire to make such a statement, it would be helpful to identify what
additional use cases such a change would address.

The statement "can be a breaker of accessibility functionality" without
specifics is weak, though in its current form is already stronger than
the corresponding statement in the original Change Proposal so it does
need to be updated until or unless that proposal is strengthened.

No changes are required to the Negative Effects, Conformance Class
Changes, or Risk sections.

- Sam Ruby

Received on Wednesday, 22 February 2012 19:59:49 UTC