Re: Chair Review of the Change Proposals for issue 179

> 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.

Glenn: please let us know your plans for this.  If we do not hear back 
from somebody who intends to address these points by March 22nd, 2012, 
we will decide in favor of the "no change" change proposal at that time.

- Sam Ruby

On 02/22/2012 02:59 PM, Sam Ruby wrote:
> 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 Tuesday, 28 February 2012 22:39:05 UTC