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

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 to Ian's response in 
<http://www.w3.org/2002/09/wbs/40318/issue-127-objection-poll/results>:

> * Fundamentally, the change here is editorial, and should be left up to editorial discretion. The suggested change is to a non-normative table, and despite claims to the contrary in the change proposal, the change will do nothing to actually affect how future link relations are designed.

The change is not purely editorial, as it *does* affect new definitions, 
and also affects registration in the IANA registry (see thread starting 
at 
<http://www.ietf.org/mail-archive/web/link-relations/current/msg00010.html>).

> * There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.

This is ISSUE-27 (<http://www.w3.org/html/wg/tracker/issues/27>); I 
think it's accurate to say that this is controversial.

> * The proposal claims to simplify the spec by removing a degree of freedom, but even if the section it proposed to change was normative, in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element), which would be a net increase in useless degrees of freedom, not a net decrease.

I'm open to tune the proposal to always treat <a> and <area> identically.

> * The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not.

See above.

> * A disallowed link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence.

That's seems to be inconsistent with how HTML5 in general handles 
non-conforming documents ("well-defined error handling").

Best regards, Julian

Received on Saturday, 5 March 2011 20:11:27 UTC