Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA

[Julian Reschke <[e-mail]>]

On 10.08.2010 22:51, Ian Hickson wrote:
>> So maybe the "new" definition is simply incorrect. Why did you change
>> it?
>
> To match real world usage.

So by doing this you broke a use case which may not be widely in use, 
but is legitimate.

>>>> - Unconvinced that<a>   and<link>   require different treatment.
>>>
>>> The simplest example of this is rel=stylesheet.
>>
>> That seems rather arbitrary, of course semantics for a/@rel=stylesheet *could*
>> be defined (scoped CSS comes to mind).
>
> Well that's as may be, but currently reality isn't so. I presume you would
> agree that the registry should match reality.

The purpose of the registry is to tell people what the semantics of a 
link relation are. It really doesn't matter whether that's already 
implemented or not.

a/@rel=stylesheet indeed is not implemented (nor precisely defined), 
thus I have no problem with HTML validators pointing out that this is 
likely an authoring mistake. I just don't see why the type registry 
needs to contain this information.

If we augment it with flags for each and every context links are used 
in, it will become hard to maintain.

>>>> - Unconvinced that the default of "no" for<link>  is right. If
>>>> somebody defines a link relation, and it doesn't make sense
>>>> on<link>, then it appears that something is very wrong with the
>>>> proposed semantics of the link relation.
>>>
>>> There are very few where this is the case, but I don't see why that
>>> would mean a relation where this is the case is wrong.
>>
>> If there are few, then this implies the default should not be "no".
>
> The "default" is merely a shorthand for not having to list every current
> relation and its new value; if you would rather I just list every relation
> I would be happy to do that.

Incorrect; it's also the default for new values.

>> That being said, I don't see anything in the definition of<link>  which
>> makes it different from what the HTTP Link header, for instance,
>> defines. Maybe you could elaborate?
>
> Elaborate on what? I didn't mention Link: headers here? I would not want
> to presuppose how Link: headers should work; I've already sent feedback on
> the Link: header work which has been rejected (e.g. the HTTP Link: header
> doesn't define how rel=stylesheet should work with the CSSOM, but that is
> apparently out of scope of the Link: header), so clearly my understanding
> of that issue is not complete. As such, I would certainly not want to
> presume to apply conformance requirements on usage of that header.

OK. So I'll just state: if a link relation doesn't have the same meaning 
in <link> and in Link: (the header field), there's a problem with the 
link relation, and we shouldn't register it.

>>> The issues had in fact been decided in an appropriate venue; I was
>>> surprised to find any resistance in the registration.
>>
>> There was no conscious decision. As a matter of fact, there's a related
>> bug (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10172>), which
>> hasn't been processed yet.
>
> That's a different venue. The registration template links to a WHATWG
> specification, where this issue was considered and decided appropriately.

So ignoring bug reports in W3C Bugzilla (which you yourself use as issue 
tracker for the WHATWG spec) means "was considered and decided 
appropriately"?

>> That's why we'd want the links to point at a published draft, not at
>> work-in-progress.
>
> The WHATWG spec is a published draft standard.

Obviously we disagree on this.

Best regards, Julian