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

In CMIS, URIs are opaque and we do not impose any constraints on how URIs
are formed.  Navigation is done through link relations - up and down.
Traditional computer science tends to use parent for a direct ancestor (see
graph/tree models) and ancestor for any node above that specific node in
the hierarchy.  IMO, 'ancestor', 'parent', 'child', and 'descendant'
terminology would be less ambiguous.

The terms 'up' and 'down' tend to provide directional information and it
would be nice if distance could also be conveyed.

I tend to read the up registration as supporting a system that supports a
node belong to more than one hierarchy (graph) and thus having more than
one parent.  I believe the divilly basic navigation draft clarifies up to
direct parent.

-Al

Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home

Office 714 327 3453
Mobile 714 263 6441
Email  albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any
attachments, are confidential and are intended solely for the use of the
person or entity to whom the message was addressed. If you are not the
intended recipient of this message, please be advised that any
dissemination, distribution, or use of the contents of this message is
strictly prohibited. If you received this message in error, please notify
the sender. Please also permanently delete all copies of the original
message and any attached documentation.



From:	Julian Reschke <julian.reschke@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/Costa Mesa/IBM@IBMUS
Date:	08/31/2009 12:04 AM
Subject:	Re: Last Call: draft-nottingham-http-link-header (Web Linking)
            to 	Proposed Standard



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