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

> -----Original Message-----
> From: []
> On Behalf Of Mark Nottingham
> Sent: Wednesday, August 19, 2009 4:55 PM
> On 31/07/2009, at 10:20 AM, Ian Hickson wrote:

> > It might also be worth considering separating the Link: header and the
> > registry into two different specifications. This would also help clarify
> > how a specification should refer to the registry.
> How do others feel about this? I'm disinclined to do so unless there's
> considerable value in it. I could see adding a new appendix suggesting
> things that new applications of linking that use this framework,
> however; would that be useful?

Doesn't seem worth the hassle.
> > The Link: header has a "rev" attribute. I would recommend dropping
> > it for
> > consistency with HTML5; we discovered in examining typical usage that
> > people generally didn't understand how to use rev="", and it is
> > redundant
> > with rel="" anyway. If it is kept, then please define how it works.
> > Allowing something but leaving it undefined is the worst of both
> > worlds.
> > (The ideal would be to define how it works but not allow it, IMHO.)
> It was included because it's in the syntax of RFC2068, but I agree
> that it's not desirable to perpetuate it. How do people feel about
> further removing it (i.e., it will be an extension, not called out
> explicitly in the syntax)?

We should drop it, again... (not sure why it came back in a previous draft). There is nothing stopping those who want it from giving it a proper definition and defining it as an extension.
> > The link relations should better define how to handle interactions
> > between
> > multiple link types, so that alternate stylesheet can be well-
> defined,
> > and so that we can define rel="up up up" as in HTML5.
> I think the general consensus is that this is bad practice, but if
> HTML5 wants to define semantics around cardinality, it can do so when
> it defines how that relation is interpreted within the scope of its
> application. I.e., mapping "up up up" to specific behaviours is the
> job of HTML5, not the link framework.
> It's worth mentioning here that because HTML5 defines both a syntax
> and what is effectively an application of linking (roughly, "web
> browsing"), it needs to define both the syntax for links and the
> behaviours associated with them.

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.
> > 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? 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).
> > Unless there are really strong use cases, I think that the anchor=
> > attribute should be dropped. In practice, implementations today
> ignore
> > that attribute, which would mean that, e.g., a
> rel=stylesheet;anchor=a
> > link would fail to have the "right" effect. If it is kept, then the
> > right
> > behaviour for how this should integrate with style sheet linking
> > should be
> > defined in great detail.
> I think that at the very least, it needs to be specified that the
> anchor attribute is not used by default; i.e., specific applications
> of linking need to specify that the anchor attribute is to be used.
> I'm also amenable to deprecating or removing it, but would like to
> hear from others about this.

Are there any documented use cases for it? If not, I suggest we drop it.


Received on Thursday, 20 August 2009 00:12:33 UTC