- From: Noah Slater <nslater@tumbolia.org>
- Date: Mon, 31 Aug 2009 07:59:00 +0100
- To: Sam Johnston <samj@samj.net>
- Cc: Eran Hammer-Lahav <eran@hueniverse.com>, Ian Hickson <ian@hixie.ch>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Aug 31, 2009 at 08:39:30AM +0200, Sam Johnston wrote: > That's an interesting idea - expanding on it: > > Link: <http://example.com>; rel="ancestor"; gen[eration]="1" Not sure if you intentionally changed it to "ancestor" here, but I certainly wouldn't want to start mint a new relationship name when "up" already has some modest use in the wild. > Generation would be 1 for parents, 2 for grandparents, 3 for > great-grandparents etc. > > Another thing I saw before - nobody mandates that ancestry information be > reflected in the URL path segments so the suggestion to "reverse engineer" > ancestors from the URL fails in my mind. I wasn't suggesting some new and wonderful technique here. The "/" character has special meaning within a URI, as do "." and "..", and as much as we like to tell ourselves that URIs are opaque, folk wisdom tells us that we can usually treat them like UNIX filenames. Power users "hack" URIs to navigate, and there are browser extension that automate it for everyone else. My suggestion to base the depth information on parsing the URI has some grounding in current practice. Sure, you could be pedantic, and use UUIDs for all your URIs. And if you did, I guess you'd have a bit of a problem trying to represent hierarchy depth in your relations. How common is this though? And moreover, you could use the order of the relation to indicate depth. Best, -- Noah Slater, http://tumbolia.org/nslater
Received on Monday, 31 August 2009 06:59:49 UTC