Re: [link-relations] NEW APP DATA

[Ian Hickson <[e-mail]>]

On Tue, 10 Aug 2010, Julian Reschke wrote:
> On 10.08.2010 09:53, Ian Hickson wrote:
> > > I explained that already. Define behavior for user agents (as 
> > > discussed last year), not HTML-specific validity constraints.
> > 
> > The proposal does both. Are you saying I should file separate 
> > registrations for whether something is a hyperlink or an external 
> > resource link, and whether something is allowed on<link> or<a>/<area>? 
> > I suppose we could do that but that would just make the interface with 
> > the HTML spec a bit more complicated, and I don't understand how that 
> > would help anyone. Are other languages also interested in the 
> > distinction between hyperlinks and external resource links? I assumed 
> > this was just an HTML issue.
> 
> Actually, I'd prefer a single flag for link/external resource (and yes, 
> this may affect other languages as well), and keep the conformance 
> related flags out of the IANA registry (but again, this is just the 
> opinion of one of the D.E.s).

I see.


> So, taking another example where the flags are different for <link> and 
> <a>/<area>: why is "bookmark" disallowed on link?

Because it wouldn't make any sense on <link> as defined. This is why 
conformance is an inherent part of the keywords. In fact, I am surprised 
other uses of these keywords don't have the same problem. For example, if 
we added "bookmark" (replacing the current registration which doesn't 
match real world usage of the keyword) to the registry, then a user agent 
would be unable to properly process it in an Atom environment or when used 
with a Link: header.


> - Unconvinced that <a> and <link> require different treatment.

The simplest example of this is rel=stylesheet.


> - Unconvinced that the IANA registry needs to carry metadata for HTML
> validation.

It certainly would be inconvenient if the HTML spec had to use two 
registries.


> - Unconvinced that the default of "no" for <link> is right. If somebody
> defines a link relation, and it doesn't make sense on <link>, then it appears
> that something is very wrong with the proposed semantics of the link relation.

There are very few where this is the case, but I don't see why that would 
mean a relation where this is the case is wrong.


> -> Proposal: just define a flag that reflects the "hyperlink"/"external
> resource" distinction.

I'll have to think about this. It's unclear to me that this would be the 
most convenient mechanism.


On Tue, 10 Aug 2010, Mark Nottingham wrote:
>
> My (possibly and perhaps mercifully uninformed) view is that the issues 
> you're discussing are specific to HTML5, and should be decided in the 
> appropriate venue before bringing this forward for registration; the 
> link relations registry is relatively neutral about how and for what the 
> appdata fields are used for.

The issues had in fact been decided in an appropriate venue; I was 
surprised to find any resistance in the registration.


> I will say that appdata fields are expensive in the sense that once 
> they're added, they persist. So, we need to make sure that this is how 
> they'll actually be specified before they're added to the registry. This 
> is why adding new appdata fields is Specification Required, which 
> implies permanence.

Sure.


> P.S. Ian - when you do register something, convention dictates that the 
> template (which you've pasted below) actually go in the document itself.

Ah, ok. This is unclear in the registry's specification, which says to 
mail the template to the list.


On Tue, 10 Aug 2010, Mark Nottingham wrote:
> 
> This registration is a bit unusual, in that you're registering using 
> whatwg.org URIs, when the W3C -- an organisation that the IETF 
> recognises as producing Open Standards --- as per RFC2026 -- is 
> producing a specification that is substantially the same.
> 
> While whatwg.org isn't necessarily precluded from meeting the 
> prerequisites of Specification Required (and therefore making 
> registrations), we want to make sure that this isn't conflicting with 
> ongoing W3C work.

On Tue, 10 Aug 2010, Philippe Le Hegaret wrote:
> 
> I see no reason here why the registration cannot point to the W3C 
> specification. The W3C HTML Working Group is producing the specification 
> for HTML, and pointing to somewhere would undermine the current process 
> and effort happening within W3C.
> 
> Ian, is there a reason why it isn't the case?

The WHATWG is also producing the specification for HTML, so by that line 
of argument, pointing to somewhere other than the WHATWG would also 
undermine the current process and effort happening within the WHATWG.

But that's clearly nonsense. It doesn't make the slightest difference to 
ongoing work what the URLs are. :-)

I used the WHATWG URLs because the W3C doesn't publish a version of the 
"complete.html" file that I used in the registration, and because the 
WHATWG documents are generally more convenient to work with than the W3C 
ones (e.g. it has bug filing tools, nicer styling, etc). Also, the WHATWG 
URLs are more stable than the W3C ones at this point (the W3C keeps taking 
things out, splitting the specs into other specs, etc), and I didn't want 
to have to keep updating the registration.

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