On Mon, Aug 31, 2009 at 09:04:40AM +0200, Julian Reschke wrote:
>> 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?
Well sure, but my experience lead me to believe that the situation I describe is
the most common one. I was also aware of the vague nature of the description,
fitting with the other relations, and a bonus for reasons I have described in a
previous email. What I meant is, a post-hoc explanation of my thought process is
hardly normative for the official registration. Hehe.
>>> 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.
Sure, seems like a reasonable, and not unexpected, use.
> Now that I realize that "up" does not refer to a specific hierarchy
> level this may need to change, though...
I'm not sure what this means.
Before I made my application to IANA, I did took the time to look around at what
seemed to be the status-quo. I was definitely swayed by HTML5 having chosen this
relationship name. And despite me not liking the use of "up up up" for depth, I
do not think this contradicts the existing IANA registration.
Best,
--
Noah Slater, http://tumbolia.org/nslater