W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: ISSUE-127: link-type-flags - Straw Poll for Objections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 10 Mar 2011 17:53:59 +0100
Message-ID: <4D790227.1090002@gmx.de>
To: Paul Cotton <Paul.Cotton@microsoft.com>
CC: "public-html@w3.org" <public-html@w3.org>
On 04.03.2011 19:35, Paul Cotton wrote:
> ISSUE-127: link-type-flags - Straw Poll for Objections
>
> The poll is available here and it will run through Friday March 11:
>
> http://www.w3.org/2002/09/wbs/40318/issue-127-objection-poll/
>
> Please read the introductory text before entering your response.
>
> In particular, keep in mind that you don't *have* to reply. You only
> need to do so if you feel your objection to one of the options is truly
> strong, and has not been adequately addressed by a clearly marked
> objection contained within a Change Proposal or by someone else's
> objection. The Chairs will be looking at strength of objections, and
> will not be counting votes.
>
> /paulc
> ...

Here's a comment on Aryeh's feedback in 
<http://www.w3.org/2002/09/wbs/40318/issue-127-objection-poll/results>:

> I object to allowing people to waste the Working Group's time with issues that are purely aesthetic. Discussing whether a particular example is misleading, or what exact normative reference we should use for something, at least makes some theoretical difference to someone. But there is no credible claim anywhere in this Change Proposal that the proposed change, by itself, will make any difference to anyone or anything now or in the future.

This issue is not purely "aesthetic". It affects registrations of new 
link relations.

> There are a few places that look like they might argue for some benefit to adopting the change, but they don't stand up to scrutiny:
>
> 1) "The semantics of a link relation should not vary too much depending on where it appears." But as the Change Proposal itself points out, the semantics of all existing link relations in the spec do not vary at all depending on where they appear, either before or after this change. Thus this is not an argument in favor of the change.

The format of the registry currently *allows* them to vary.

> 2) "to encourage consistent semantics across elements". How will this result from the change? Is the proposer arguing that after adopting the change, the editor will be less likely to introduce new link types with inconsistent semantics across elements? (As I read the proposal, it doesn't prevent the editor from introducing such relations later if he likes.) No evidence or reasoning is presented to support this point, so it should be disregarded.

I don't understand this point. The current format allows the relation to 
have a different effect on the various elements; the new format does not.

> 3) "to simplify the spec", "Removal of an unused degree of freedom in defining link relations". These are purely aesthetic benefits, whose merits are entirely debatable, and are in fact debated by the editor. We should not allow Change Proposals to be based on entirely subjective aesthetic judgments, only on quantifiable technical arguments. Even if we were to permit aesthetic arguments, however, there is no actual argument presented for why this simplification or removal of freedom is a good thing. We are asked to accept this as self-evident, but it's actually contested, so arguments must be presented in favor for it to be considered.

You are repeating yourself :-)

> 4) "consistency with link relations in other contexts." No explanation is given for why the change would increase consistency with link relations in other contexts. HTTP and Atom are mentioned, but no explanation is given of how link relations are treated by HTTP or Atom, or what relevance the proposed change has. Since the proposed change would (by the proposer's own admission) have no impact on how any of the link relations in HTML function, and is merely a change to how the existing functionality is presented, it's hard to imagine how it could improve consistency with anything. Fortunately, we are not tasked with using our imagination here, and should again reject this point for failing to present supporting evidence.

The context is here: 
<http://www.ietf.org/mail-archive/web/link-relations/current/msg00000.html> 
plus the subsequent mails.

Summary: the IANA link relations registry allows additional attributes 
to be added to the registry; this was a feature requested by members of 
*this* Working Group. The email thread is about figuring out the right 
format of these additional attributes.

> I could not find any other purported benefits of the change. Thus in summary, there are five claimed benefits, and none of them have any supporting arguments at all. It's not just that the supporting arguments are weak, they aren't present. The absence of any arguments in favor of the change means that we maintain the status quo.
>
> I encourage the chairs to make it clear that Change Proposals will not be adopted if they merely assert that some way of phrasing or presenting things is clearer or simpler or easier to read, even if they invoke trivial arguments such as "shorter things are easier to read". Such changes are not going to bring any benefit that comes close to outweighing the effort expended in processing them, and will unduly delay progress along the Recommendation track. No other W3C Working Group that I'm aware of will even consider such objections -- thus the term "editorial issue". Editorial issues should only be subject to oversight if there's an argument that they could meaningfully mislead or harm readers of the spec.

Actually, shorter things *are* easier to read, but I don't see what this 
has to do with the change proposal we're discussing.

It appears you do not understand the underlying reason for this change 
proposal; this could be my fault for not explaining well enough, but it 
could also be caused by you not caring about things outside the HTML world.

Best regards, Julian
Received on Thursday, 10 March 2011 16:54:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:25 GMT