Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On Thu, 20 Aug 2009, Mark Nottingham wrote:
> On 31/07/2009, at 10:20 AM, Ian Hickson wrote:
> >
> > Comparing relation types case-sensitively (e.g. as in 4.2 Extension 
> > Relation Types) is incompatible with HTML's processing of rel=""; I 
> > would like to request that all relations always be case-insensitive.
> Is that specific to HTML5? How does HTML5 process rel?

All versions of HTML have been case-insensitive throughout their rel="" 
procesing, as far as I can tell.

> > The spec should clearly say which takes preference if both title= and 
> > title*= are given. Also, the spec should clearly say which takes 
> > preference if multiple title=, type=, etc, attributes are given.
> Ack.

I assume you mean "acknowledged", not "ew". :-)

> > I think for the best compatibility with legacy implementations, the 
> > spec should say that there must only be one occurance of each 
> > attribute, and that multiple link types in one Link: header should be 
> > listed in one rel="" attribute. (That is, only allow rel="a b", not 
> > rel=a;rel=b.)
> Do you have data to back this up?

As far as I can tell, Mozilla only supports one of each attribute. Are 
there UAs that support more?

Given that HTML and Atom only allow one of each attribute, I think we're 
far less likely to have bugs if we say that all but the first occurrance 
of each attribute is just ignored.

> I'm concerned that this would disallow internationalisation of title, 
> for example (e.g., you couldn't express both an english and a spanish 
> title for a link).

That sounds like one of those things that looks good on paper but doesn't 
really ever translate to implementations. Are we really expecting authors 
to provide multiple titles per link? How would that work in UI?

> > I would like to request that each link type be defined as either being 
> > a hyperlink or an external resource link, as defined in HTML5, and 
> > that this be added as one of the things that must be defined in the 
> > registry.
> I'm not sure what an "external resource link" is, could you please 
> remind me?

When you mirror a page ("Save As ... Complete" or "Save As ... Archive"), 
external resource links are those that are fetched and included with the 
source document, whereas hyperlinks are those that are considered to be 

A style sheet, for instance, is an external resource link. A regular <a 
href=""> is just a hyperlink.

> > Similarly, the registry should define whether or not link relations 
> > are allowed at the document level (<link rel>, Link:) and at the 
> > phrasing level (<a rel>, <area rel>). Some types in HTML5 only apply 
> > to one or the other.
> That's a job for HTML5 as an application of the relations, not the 
> registry.

So every time someone adds something to the registry, we have to update 
HTML5 to say whether that keyword can be used with HTML?

> > Ideally, I would like the Link: header section to more clearly define 
> > how some of the keywords defined in the spec should actually be used. 
> > For example, how should the rel=stylesheet keyword affect the CSSOM? 
> > Where do resources imported in this way fall in the CSS cascade? How 
> > should it affect documents with MIME types like text/plain? Do 
> > rel=icon links interact with those specified in the document? If so, 
> > where should they be considered as falling in terms of tree order?
> Again, a job for HTML5.

Why should HTML5 define how rel=stylesheet of a CSS file applies to an XML 
document? That doesn't sound right at all.

It's the linking mechanism, in this case the Link: header, that should 
define how it works, just like how HTML5 defines how <html:link> works in 
XML, or how the XML Style Sheet PI spec defines how <?xml-stylesheet> 
works in XML.

> > I would like to request that the registration mechanism be made 
> > significantly simpler than the one described in the spec. For example, 
> > a simple mechanism could be just to edit a wiki listing all the 
> > extensions.
> In the IETF, IANA is the mechanism for managing registries like this.

Regardless of who manages the registry, I would like to request that the 
registration mechanism be made significantly simpler than the one 
described in the spec.

> > I would like to request some guidance on what HTML5 would have to do 
> > to be compatible with this draft, and what benefits would come from 
> > it. There are clear benefits to the Link: header section, assuming 
> > that how it fits into the general Web platform is defined (as 
> > requested above). But how does the registry fit into the RelExtensions 
> > registry for HTML5? How should they interact?
> If HTML5 chooses to adopt this framework, it would need to:
>   1) Define the syntax for serialising and parsing links in HTML5, using the
> terms defined in the draft (see Appendix C), and

Does what HTML5 already says on the matter satisfy this?

>   2) Associate concrete behaviours with the general semantics of the
> registered link relations it finds interesting, and

I don't understand how we can do that since most of the link relations 
that people will want to use with HTML5 haven't even been thought of yet.

>   3) Define how undefined / unrecognised relations are to be handled (with a
> heavy bias towards must-ignore), and


>   4) Optionally, define additional registered and/or extension link relations.

Ok. Is what HTML5 already has for this adequate?

> > The "up", "first", "last", and "payment" types are woefully 
> > underdefined. What is the expected UA behaviour when discovering a 
> > link with rel=payment? What are the authoring requirements? What are 
> > the implementation requirements?
> I'd agree that "payment" is ill-defined, but most of the questions you 
> ask need to be answered (once again) in the context of a particular 
> application of linking, not by the registry.

So how rel=payment works will differ for Atom and for HTML?

It seems pointless to have a registry at all, if the behaviours are scoped 
to each use of the term, rather than being related to the term.

On Wed, 19 Aug 2009, Eran Hammer-Lahav wrote:
> Combining rel values is an awful idea. If someone wants 'up up up' they 
> should define a rel value of it like up-n (up-1, up-2, etc.). Being able 
> to indicate multiple relation types for a given link is an important 
> part of the link architecture and clients should not need to look for 
> how rel values change the meaning of each other.

We're past this already with rel="alternate stylesheet", and to be honest, 
I don't really see what's that wrong with it, except for the overloading 
of the keyword "alternate".

The main advantage of rel="up up up" rather than rel="up3" is that for UAs 
that only need to know that the link is an "up" and don't care about how 
far "up" it goes, the keyword automatically works -- you don't have to do 
rel="up up3". Also, it means that we don't have to register an infinite 
number of keywords for all possible depths.

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

Received on Sunday, 30 August 2009 02:21:51 UTC