Re: [link-relations] NEW APP DATA

[Ian Hickson <[e-mail]>]

On Mon, 9 Aug 2010, Julian Reschke wrote:
> On 09.08.2010 19:50, Ian Hickson wrote:
> > On Mon, 9 Aug 2010, Julian Reschke wrote:
> > > > 
> > > > The purpose of those flags is to define conformance for HTML.
> > > 
> > > Yes. I'm not convinced that it's a good idea to move this into the 
> > > IANA registry
> > 
> > Nor am I, but that is what the registry was designed to do.
> 
> Maybe it's just me, but I don't think it was designed for that.

Well, the field registry exists so as to make it possible to use the 
registry for HTML, as I understand it. But maybe I'm mistaken, and we're 
not supposed to use the registry for HTML relations? I'm confused now.


> > > nor am I convinced that the individual flags and their defaults make 
> > > sense.
> > 
> > Ok... Do I have to convince you for the fields to be registered?
> 
> There are three designated experts, and I assume you need to convince at 
> least one of them. I'm one of those.

I see.

How can I convince you?


> > > > Relations can be updated to define how they work with HTML by 
> > > > using the process described in the Web Linking spec.
> > > 
> > > Do you think it's necessary to do so? Be default, I'd expect any 
> > > link relation that we have to be usable with<link> by default. It 
> > > would be very useful to understand why this wouldn't be the case.
> > 
> > It's certainly not the case that any link relation is relevant 
> > anywhere. Suppose someone designed a link relation whose purpose was 
> > to identify a resource that should be notified any time an API call 
> > was made on an HTMLDocument object. That presumably wouldn't make any 
> > sense in an Atom feed. Similarly, consider "edit" or "edit-media". 
> > While they may be well-defined in the context of Atom, they certainly 
> > are not defined to a level that is clear enough for it to make sense 
> > to use them in an HTML document, so we wouldn't want to have an author 
> > accidentally use them (especially if they were just using them because 
> > they thought they could make up new relations and just accidentally 
> > clashed with the Atom ones).
> 
> My understanding is that we want *future* registered link relations to 
> be broadly usable. So for the example you just mentioned I don't see how 
> a registration would suceed.

Well it would be a pretty useless registry if it didn't match reality. :-) 
I would presume that if someone implemented such a value, getting it 
registered would be near-automatic, since otherwise we're just going to 
end up with clashes because people won't be able to register the values 
they're using, no?


> > > Are you confident that<a> and<area> always have the same 
> > > requirements?
> > 
> > They currently do. If that changes, we'll update the registries. Who 
> > knows what the future holds.
> 
> And add yet another column to the generic registry?

Are columns expensive?


> > > > rel=noreferrer to be allowed on<link> because it's not a link 
> > > > relation, it's a link annotation, and<link> doesn't create 
> > > > hyperlinks without a relation that creates one. Each keyword would 
> > > > have to be taken on a case- by-case basis.
> > > 
> > > I can see that noreferrer being the only link relation on a<link> is 
> > > meaningless, but that doesn't mean it needs to be disallowed; there 
> > > could be other rel values present, after all.
> > 
> > If something is meaningless, the author benefits from being informed 
> > of this, since it is unlikely to be his intent. That's what 
> > conformance checkers, and thus conformance definitions, are for.
> 
> The point being it's only meaningless (in HTML) when it's the *only* 
> link relation on the link. Thus, it doesn't make sense to forbid
> 
>   <link rel="noreferrer stylesheet" ...
> 
> just because
> 
>   <link rel="noreferrer" ...
> 
> might be an authoring mistake.

That's possible, but that's an issue for HTML, not for the registry, no?


> > > > Regarding the final parenthetical, I believe the templates fit 
> > > > what is described in the Web Linking spec.
> > > 
> > > It does, this is an oversight in the spec. So we'd have to figure 
> > > out unique names upon registration.
> > 
> > I'm just trying to do what the spec says here.
> 
> In the meantime, what's your take on the part of my email you skipped?

> Going back to the original issue (hopefully providing context for
> those who weren't there): we discussed application-specific data
> when we met in Santa Clara last November. The use case that was
> provided was a flag that would allow user agents to decide what kind
> of links need to be followed when going offline or archiving a
> resource. That makes a lot of sense, and I'd support that kind of
> flag, hopefully described in a way that isn't totally specific to
> HTML.

I have no opinion on this.


> What you are proposing is much more; it augments the link type
> registry with validation hints. I'm totally unconvinced that this is
> a good idea; in particular given the fact that it's an open question
> in the HTML WG how far validation should go with respect to these
> values.

I see. Not sure what to do about that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'