Re: [link-relations] NEW APP DATA

[Julian Reschke <[e-mail]>]

On 09.08.2010 21:10, Ian Hickson wrote:
> ...
>> Maybe it's just me, but I don't think it was designed for that.
>
> Well, the field registry exists so as to make it possible to use the
> registry for HTML, as I understand it. But maybe I'm mistaken, and we're
> not supposed to use the registry for HTML relations? I'm confused now.
 > ...

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.

 > ...
>>> 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.
>
> I see.
>
> How can I convince you?
 > ...

1) You could re-consider the default ("not valid").

2) You could rephrase the application flags in a more generic way (as 
discussed last November).

..also, in the HTML WG, we really need to discuss whether conformance 
checkers ought to check link relations.

> ...
>> 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.
>
> Well it would be a pretty useless registry if it didn't match reality. :-)
> I would presume that if someone implemented such a value, getting it
> registered would be near-automatic, since otherwise we're just going to
> end up with clashes because people won't be able to register the values
> they're using, no?
> ...

If someone tried to register that relation, I'd probably propose to use 
an extension relation type instead, or to prefix the short name with 
something that makes it clear it's very application-specific.

So, no, there is no automatism.

>>>> 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?
>
> Are columns expensive?

Yes, because it makes all future registrations more complicated. I'd 
expect new columns to be an exception.

Mark?

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

>>>>> 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?
>
>> Going back to the original issue (hopefully providing context for
>> those who weren't there): we discussed application-specific data
>> when we met in Santa Clara last November. The use case that was
>> provided was a flag that would allow user agents to decide what kind
>> of links need to be followed when going offline or archiving a
>> resource. That makes a lot of sense, and I'd support that kind of
>> flag, hopefully described in a way that isn't totally specific to
>> HTML.
>
> I have no opinion on this.

Well, it's the use case you brought up (as far as I recall), and why the 
application data registry was added.

I think it's a good use case, and I expected that this would be the 
application data you're going to register.


>> What you are proposing is much more; it augments the link type
>> registry with validation hints. I'm totally unconvinced that this is
>> a good idea; in particular given the fact that it's an open question
>> in the HTML WG how far validation should go with respect to these
>> values.
>
> I see. Not sure what to do about that.

One approach would be to simplify the application data as described 
above, and consider the remainder (if needed at all) something local to 
HTML.

Best regards, Julian