- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 31 Aug 2009 09:04:40 +0200
- 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