Re: [link-relations] NEW APP DATA

[Julian Reschke <[e-mail]>]

On 09.08.2010 23:47, Ian Hickson wrote:
> ...
>> Yes, we want a registry that can be shared among HTML, Atom, HTTP, and
>> other users of link relations.
>>
>> But that doesn't necessarily imply that a specific application needs to
>> off-load everything it wants into that registry.
>
> It's unclear to me how I am supposed to use the registry then.
> ...

Just mentioning the options: one approach would be to have a second 
place for the additional information, another one would be to reconsider 
whether the additional information actually makes 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.
>>>
>>> How can I convince you?
>>
>> 1) You could re-consider the default ("not valid").
>
> The default only applies to the existing relations, right? I didn't really
> want to pick a default at all, I just wanted to list the values for the
> keywords I was familiar with, and wanted to let the people who'd
> registered the other values determine the values if they wanted their
> keywords usable with HTML.

Yes, and again: I do not see why any of those would not be allowed in 
HTML, so I really think you have chosen the wrong default value.

> I'm happy to change the "default" to something else and just list the
> values differently, but that just seems like busywork, it wouldn't
> actually change anything in the registry.

It would change the value the existing registrations get.

>> 2) You could rephrase the application flags in a more generic way (as
>> discussed last November).
>
> It's unclear what this would mean. I don't think making things "generic"
> makes sense here. We're trying to solve a very specific problem for this
> application (HTML), for which we need specific data... how would we make
> this generic?

I explained that already. Define behavior for user agents (as discussed 
last year), not HTML-specific validity constraints.

> ...
>>>> 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.
>>>
>>> That's possible, but that's an issue for HTML, not for the registry,
>>> no?
>>
>> Yes, the registry should just allow "noreferrer". That's my point.
>
> Surely we don't want to update HTML each time there's a change to the
> registry? Or is that what you're saying we should do? I don't understand.

What I'm saying is that "noreferrer" should be allowed on <a>/<area> and 
<link>; as far as I can tell, your proposal disallows it for <link> 
(consistent with HTML5, so this is a bug in HTML5), and also disallows 
it for <a>/<area> (which seems to be a bug in your registration).

(There may be more problems, I just checked this one).

Best regards, Julian