Re: link relation metadata considerations, also ACTION-186

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

Received on Saturday, 21 August 2010 17:37:03 UTC