Re: [link-relations] NEW APP DATA

[Ian Hickson <[e-mail]>]

On Mon, 9 Aug 2010, Julian Reschke wrote:
> On 09.08.2010 21:10, Ian Hickson wrote:
> > >
> > > 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.
> 
> Yes, we want a registry that can be shared among HTML, Atom, HTTP, and 
> other users of link relations.
> 
> But that doesn't necessarily imply that a specific application needs to 
> off-load everything it wants into that registry.

It's unclear to me how I am supposed to use the registry then.


> > > > 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.
> > 
> > How can I convince you?
> 
> 1) You could re-consider the default ("not valid").

The default only applies to the existing relations, right? I didn't really 
want to pick a default at all, I just wanted to list the values for the 
keywords I was familiar with, and wanted to let the people who'd 
registered the other values determine the values if they wanted their 
keywords usable with HTML.

I'm happy to change the "default" to something else and just list the 
values differently, but that just seems like busywork, it wouldn't 
actually change anything in the registry.


> 2) You could rephrase the application flags in a more generic way (as 
> discussed last November).

It's unclear what this would mean. I don't think making things "generic" 
makes sense here. We're trying to solve a very specific problem for this 
application (HTML), for which we need specific data... how would we make 
this generic?


> ..also, in the HTML WG, we really need to discuss whether conformance 
> checkers ought to check link relations.

That seems out of scope for this particular thread.


> > > 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?
> 
> If someone tried to register that relation, I'd probably propose to use 
> an extension relation type instead, or to prefix the short name with 
> something that makes it clear it's very application-specific.

Ok well that seems somewhat off-topic for this registration so I guess we 
should leave this for another thread.


> > > 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?
> 
> Yes, the registry should just allow "noreferrer". That's my point.

Surely we don't want to update HTML each time there's a change to the 
registry? Or is that what you're saying we should do? I don't understand.

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