[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Input on request for link relation



On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur <hadrien.gardeur@xxxxxxxxxxxxx> 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" 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@xxxxxxxx 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