W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Sun, 30 Aug 2009 23:30:18 -0700
To: Ian Hickson <ian@hixie.ch>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784B2ACAE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Saturday, August 29, 2009 7:24 PM
> 
> 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".

One bad legacy example doesn't mean we are past this. Following this logic we should never deprecate anything if it is deployed somewhere...

The problem is that it will break clients unaware of this overloading. A client today with support for a set of relation types should not break when another relation type overloads the meaning of a well defined type. The ability to ignore unknown relation types and use the familiar ones is an important capability. Clients must be able to follow the links that make sense to them.

What this combination nonsense is doing is putting well-understood relation types into question when another relation type is present. You simply cannot have it both ways: multiple independent values and combinations.
 
> 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.

This is really not a compelling use case. Are there other use cases?

As for 'up', its definition is too ambiguous to support these combinations. It is currently registered as: "A URI that refers to a parent document in a hierarchy of documents." I can't figure out if 'a parent' can be any parent of a direct parent. If it means a direct parent, your theory of 'automatically works' breaks because UAs will expect the document to be the direct parent, not just a document somewhere 'up' there. If it means any parent, then you can't express a direct parent, but can express a second direct parent.

If you don't want to register multiple 'up-n' relations, consider defining the relation type with an optional extension, such as:

Link: <http://example.com>; rel="up"; level="2"

And it would be better if the 'up' registration entry was more clear indicating it can indicate *any* parent, not just a direct parent. This way, a client always understand what the relation means, but can also support finer details with an extension.

EHL
Received on Monday, 31 August 2009 06:30:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:09 GMT