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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 31 Aug 2009 09:04:40 +0200
Message-ID: <4A9B7608.4010806@gmx.de>
To: Eran Hammer-Lahav <eran@hueniverse.com>, Ian Hickson <ian@hixie.ch>, HTTP Working Group <ietf-http-wg@w3.org>
CC: Al Brown <albertcbrown@us.ibm.com>
Noah Slater wrote:
> ...
> This is arguably a good thing.
>> 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.
> For what it's worth, my thoughts were that this would represent a resource that
> was a direct parent of the resource. And by direct parent, I mean a parent that
> must necessarily be passed through if traversing the hierarchy. For the purpose
> of this discussion, however, I'm not sure my original intentions matter.

Well, you did register the link relation, right?

>> 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"
> I'm going to go out on a limb and suggest that most hierarchical relationships
> that people will want to express will be such that the level can be inferred
> directly from the URI. More over, I fail to understand what kind of UA interface
> would need or want this kind of detail.

CMIS/AtomPub is an example where the hierarchy is not necessarily 
reflected in the URIs, and that's why people want to use the "up" relation.

Now that I realize that "up" does not refer to a specific hierarchy 
level this may need to change, though...

> ...

BR, Julian
Received on Monday, 31 August 2009 07:18:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC