Unfortunately, I haven't seen any feedback on this.
...adding some more thoughts before adding issues to BugZilla. See below:
> OK, here we go.
>
> Let's have a look at <http://dev.w3.org/html5/spec/links.html#linkTypes>.
>
> Observations:
>
> a) There are link types not allowed on <link>.
>
> b) There are link types not allowed on <a>/<area>.
>
> c) *When* a link type is allowed on both, the "effect" is the same for
> both.
>
>
> Questions I'd like this Working Group to consider:
>
> 1) What's the use case for link relations not allowed on <link>?
>
> Right now, there are four:
>
> bookmark: the only reason this *currently* doesn't make sense page-wide
> is because the definition was changed from what HTML4 said.
>
> external, nofollow, noreferrer: no idea why they would be disallowed.
I'll add individual bugs "bookmark" and "external". I already did so for
"nofollow" and "noreferrer" four weeks ago
(<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10172>, rejected by the
editor, thus will be added to the issue tracker soonish).
> 2) If there are currently no cases where the "effect" on a link would
> depend on whether it's <link> or <a>/<area>... maybe this distinction is
> meaningless, and a better categorization would be:
>
> i) what the effect is on links in general (no matter where they appear),
> and
>
> ii) where they are allowed (in that if they are not a conformance
> checker would complain).
For i) I can think of two approaches:
a) define "link relation classes" as proposed in HTML5 ("hyperlink",
"external resource", "annotation"), and add this as one application data
field to the link registry.
It's pretty clear how this could be used in general: a "hyperlink" (or
"link?") is just a link with no additional properties relevant for
general processing. An "external resource" is something a link-following
processor would want to follow when archiving a resource, or saving it
for offline use.
An "annotation" isn't a *real* link relation, as the information only
augments the link it's on. Validators could use this information to flag
links that *only* have an annotation (this applies to HTML <link>
element, the <atom:link) element, and the Link: HTTP header field, for
instance).
I think this looks good if we're sure that there aren't any classes we
need to add in the future.
b) Thus, maybe flags would make more sense: "required" (-> "external
resource") and "annotation" (a link needs a non-annotation relation to
be complete).
With this approach we'd need two flags, but they'd be binary.
For ii) (the conformance-on-certain-elements question) I'm still not
convinced that this information needs to go into the generic registry;
and I'm also not convinced that not having the data in the generic link
registry would mean it's not useful for HTML; it just would be *less*
useful. *If* we add this information it really should be orthogonal to
the link relation *classification*; otherwise the information would be
*only* be useful for HTML, and I hope we can agree that this would be
sub-optimal.
> ...
Best regards, Julian