Re: [link-relations] NEW APP DATA

[Julian Reschke <[e-mail]>]

On 09.08.2010 19:50, Ian Hickson wrote:
> On Mon, 9 Aug 2010, Julian Reschke wrote:
>>>
>>> The purpose of those flags is to define conformance for HTML.
>>
>> Yes. I'm not convinced that it's a good idea to move this into the IANA
>> registry
>
> Nor am I, but that is what the registry was designed to do.

Maybe it's just me, but I don't think it was designed for that.

>> nor am I convinced that the individual flags and their defaults make
>> sense.
>
> Ok... Do I have to convince you for the fields to be registered?

There are three designated experts, and I assume you need to convince at 
least one of them. I'm one of those.

>>> Relations can be updated to define how they work with HTML by using
>>> the process described in the Web Linking spec.
>>
>> Do you think it's necessary to do so? Be default, I'd expect any link
>> relation that we have to be usable with<link>  by default. It would be
>> very useful to understand why this wouldn't be the case.
>
> It's certainly not the case that any link relation is relevant anywhere.
> Suppose someone designed a link relation whose purpose was to identify a
> resource that should be notified any time an API call was made on an
> HTMLDocument object. That presumably wouldn't make any sense in an Atom
> feed. Similarly, consider "edit" or "edit-media". While they may be
> well-defined in the context of Atom, they certainly are not defined to a
> level that is clear enough for it to make sense to use them in an HTML
> document, so we wouldn't want to have an author accidentally use them
> (especially if they were just using them because they thought they could
> make up new relations and just accidentally clashed with the Atom ones).

My understanding is that we want *future* registered link relations to 
be broadly usable. So for the example you just mentioned I don't see how 
a registration would suceed.

> ...
>> Are you confident that<a>  and<area>  always have the same requirements?
>
> They currently do. If that changes, we'll update the registries. Who knows
> what the future holds.

And add yet another column to the generic registry? Hm.

>>> rel=noreferrer to be allowed on<link>  because it's not a link
>>> relation, it's a link annotation, and<link>  doesn't create hyperlinks
>>> without a relation that creates one. Each keyword would have to be
>>> taken on a case- by-case basis.
>>
>> I can see that noreferrer being the only link relation on a<link>  is
>> meaningless, but that doesn't mean it needs to be disallowed; there
>> could be other rel values present, after all.
>
> If something is meaningless, the author benefits from being informed of
> this, since it is unlikely to be his intent. That's what conformance
> checkers, and thus conformance definitions, are for.

The point being it's only meaningless (in HTML) when it's the *only* 
link relation on the link. Thus, it doesn't make sense to forbid

   <link rel="noreferrer stylesheet" ...

just because

   <link rel="noreferrer" ...

might be an authoring mistake.


>>> Regarding the final parenthetical, I believe the templates fit what is
>>> described in the Web Linking spec.
>>
>> It does, this is an oversight in the spec. So we'd have to figure out
>> unique names upon registration.
>
> I'm just trying to do what the spec says here.

In the meantime, what's your take on the part of my email you skipped?

Best regards, Julian