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

On Mon, Aug 31, 2009 at 8:59 AM, Noah Slater <> wrote:

> On Mon, Aug 31, 2009 at 08:39:30AM +0200, Sam Johnston wrote:
> > That's an interesting idea - expanding on it:
> >
> > Link: <>; 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).


Received on Monday, 31 August 2009 07:18:26 UTC