Re: Input on request for link relation

On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur <
hadrien.gardeur@feedbooks.com> wrote:
>> In line with comments I've made in other threads I think it makes sense
>> for us to limit link relation discussions to the generic relation itself
>> rather than any specific implementation of it.
>
> Several relations would need a similar treatment.

Yes, though I believe Mark's "Web
Linking<http://tools.ietf.org/html/draft-nottingham-http-link-header>"
draft does this already.

> For example:
>>
>> edit: An IRI of an editable Member Entry. When appearing within an
>> atom:entry, the href IRI can be used to retrieve, update and delete the
>> Resource represented by that Entry.
>
> BTW, what would be the generic link relation to indicate an AtomPub
> collection (only the service document is registered at IANA) ?

I started thinking about this earlier in the week with a view to having e.g.
a representation of a bookshelf referring to a collection/feed/url-list/etc.
of books using rel="collection". I then started looking at
parent/child/sibling relationships which are currently being discussed in a
separate thread (my preference is for something like e.g. "rel=descendant
level=2" for grandchildren as I subsequently realised that suggested
abbreviations "asc" for ascendant and "desc" for descendant can be confused
with item ordering). Do you think these "family" relations serve all the use
cases for a "collection" relation?

> I agree. We need a better policy for rel values. Currently, it seems that
> new rel values are added to the IANA link registry whenever a new RFC is
> adopted. These relationships could have a much broader scope and shouldn't
> be bound to particular protocols.

Great. I don't think there's much contention over this point (at least I've
not yet seen any) and the draft spells out the requirements (which can be
summarised as "broadly useful") reasonably well:

> Commonly-used relation types with a clear meaning that are shared

across applications can be registered as tokens for convenience and

to promote reuse.  For example, "self" and "alternate" are registered

relation types, because they are broadly useful.


The registry also outlines the process which involves a dedicated expert and
public comment period:

6.2.  Link Relation Type Registry


>    This specification establishes the Link Relation Type Registry, and

   updates Atom [RFC4287] to refer to it in place of the "Registry of

   Link Relations".


>    The requirements for registered relation types are described in

   Section 4.1.


>    Relation types are registered on the advice of a Designated Expert

   (appointed by the IESG or their delegate), with a Specification

   Required (using terminology from [RFC5226]).


>    Registration requests consist of the completed registration template

   below, typically published in an RFC or Open Standard (in the sense

   described by [RFC2026], Section 7).  However, to allow for the

   allocation of values prior to publication, the Designated Expert may

   approve registration once they are satisfied that an RFC (or other

   Open Standard) will be published.


>    The registration template is:


>    o  Relation Name:

   o  Description:

   o  Reference:

   o  Notes: [optional]


>    Upon receiving a registration request (usually via IANA), the

   Designated Expert should request review and comment from the

   apps-discuss@ietf.org mailing list (or a successor designated by the

   APPS Area Directors).  Before a period of 30 days has passed, the

   Designated Expert will either approve or deny the registration

   request, communicating this decision both to the review list and to

   IANA.  Denials should include an explanation and, if applicable,

   suggestions as to how to make the request successful.


Ironically the apps-discuss list wasn't included so I am adding them now.
One nitpick about the process is that it seems a request can be denied with
a suggestion for another relation (for example we might prefer to use
something like "push" or "notif[y|ier|ication|ications" rather than "hub"
for this one) but then that would require restarting the process where it
should proceed to registration immediately if the change is accepted by the
applicant.

I also question the relevance of the "reference" field in the registry as
this links relations to implementations which I think we agree is a bad
thing - the registry should capture all the necessary semantics without
reliance on external references. It may be interesting to list zero or more
implementations of the relation (that is, make the "reference" field
optional as well and allow others to add themselves to it), however I'm not
sure the maintenance load is worth the effort.

Sam