Re: link relation metadata considerations, also ACTION-186

Hi there,

more data relating to ACTION-186, due today...

- Bugzilla entry on bookmark not being allowed on <link>: 
<>; rejected by the 

- Separate mailing thread where the proposal to refactor the application 
metadata was repeated: 
<>; no 
Bugzilla issue was raised yet because I was hoping for the discussion on 
the mailing list to get somewhere.

Best regards, Julian

On 21.08.2010 19:36, Julian Reschke wrote:
> 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 <>.
>> 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
> (<>, 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 Thursday, 26 August 2010 11:48:29 UTC