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: Sam Johnston <samj@samj.net>
Date: Mon, 31 Aug 2009 09:17:31 +0200
Message-ID: <21606dcf0908310017o2dbb782eg5872d71bfa8a488a@mail.gmail.com>
To: Sam Johnston <samj@samj.net>, 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 8:59 AM, Noah Slater <nslater@tumbolia.org> wrote:

> 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.
>

Existing use equates "up" with "parent" does it not?


> > 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.
>

The case I was thinking of was mail archives which tend to be flat (with
messages numbered sequentially), where ancestry relates to threading. Anyway
there will always be an exception - we did consider using UUIDs to identify
resources for OCCI (but abandoned it along with other restrictions, like the
ones you propose, on the URL structure).

Sam
Received on Monday, 31 August 2009 07:18:26 GMT

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