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

[Julian Reschke <[e-mail]>]

On 10.08.2010 20:01, Ian Hickson wrote:
> ...
>> So, taking another example where the flags are different for<link>  and
>> <a>/<area>: why is "bookmark" disallowed on link?
>
> Because it wouldn't make any sense on<link>  as defined. This is why
> conformance is an inherent part of the keywords. In fact, I am surprised
> other uses of these keywords don't have the same problem. For example, if
> we added "bookmark" (replacing the current registration which doesn't
> match real world usage of the keyword) to the registry, then a user agent
> would be unable to properly process it in an Atom environment or when used
> with a Link: header.

So maybe the "new" definition is simply incorrect. Why did you change it?

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

>> - Unconvinced that the IANA registry needs to carry metadata for HTML
>> validation.
>
> It certainly would be inconvenient if the HTML spec had to use two
> registries.

As Mark noted, we probably should discuss whether use of relation types 
should affect document validity over in the HTML WG.

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

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?

> ...
>> On Tue, 10 Aug 2010, Mark Nottingham wrote:
>>
>> My (possibly and perhaps mercifully uninformed) view is that the issues
>> you're discussing are specific to HTML5, and should be decided in the
>> appropriate venue before bringing this forward for registration; the
>> link relations registry is relatively neutral about how and for what the
>> appdata fields are used for.
>
> 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.

> ...
> But that's clearly nonsense. It doesn't make the slightest difference to
> ongoing work what the URLs are. :-)
>
> I used the WHATWG URLs because the W3C doesn't publish a version of the
> "complete.html" file that I used in the registration, and because the
 > ...

...but another one, which is "less complete", but happens to reflect the 
W3C's view of what HTML5 is... (you know that, I know that, but maybe 
some people looking at this thread do not)

> ...
> WHATWG documents are generally more convenient to work with than the W3C
> ones (e.g. it has bug filing tools, nicer styling, etc). Also, the WHATWG
 > ...

But they are a pain to use in certain browsers due to their sheer size, 
and the scripts that are running upon load. (I'm even going to say that 
sending out these URIs almost is a DOS attack on some people's browsers).

> URLs are more stable than the W3C ones at this point (the W3C keeps taking
> things out, splitting the specs into other specs, etc), and I didn't want
> to have to keep updating the registration.

That's why we'd want the links to point at a published draft, not at 
work-in-progress.

Best regards, Julian