Subject: Re: Input on request for link relation

From: Sam Johnston <[email-masked]>
Date: Fri, 11 Sep 2009 15:17:46 +0200

On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur <
[email-masked]> 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

   [email-masked] 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

---

From: Hadrien Gardeur <[email-masked]>
Date: Fri, 11 Sep 2009 15:41:57 +0200

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

It does (Section 6.2).

> 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?
>

In AtomPub, a collection is defined as:

> A Resource that contains a set of Member Resources. Collections are
> represented as Atom Feeds.

Collections are used to indicate where you can POST a new entry in a Service
document, and what you can post is defined in app:accept:

> The content of an "app:accept" element value is a media range as defined in
> [RFC2616]. The media range specifies a type of representation that can be
> POSTed to a Collection.

In the current Web Linking draft, the edit relation is redefined (Refers to
a resource that can be used to edit the link's context.) but we still lack a
relation type for links where we can POST things (and we shouldn't use
"collection" for this purpose).
Since we can't use more than a single relation type for a link, it might be
complex to define something that is both a "collection" and a resource where
you can "post".

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Sep 2009 11:21:42 +1000

On 11/09/2009, at 11:17 PM, Sam Johnston wrote:

> 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.

Yes, but is the overhead really that onerous?

> 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.

Not to implementations, to the source documents for the registrations  
(which IANA likes to see in registries, AIUI, for paper trail etc).

It's true that the pre-populated entries have a lot of references to  
formats, but that's an artefact of history, not the direction we'll  
move in going forward.

--
Mark Nottingham     http://www.mnot.net/

---

From: Sam Johnston <[email-masked]>
Date: Wed, 16 Sep 2009 11:46:47 +0200

On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham <[email-masked]> wrote:

>  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

Perhaps not, and there could well be some delay in acceptance if committees
are involved. My worry is that if we don't streamline our processes as much
as possible (see Ian's suggestion about IANA maintaining a
RelExtensions<http://wiki.whatwg.org/wiki/RelExtensions>style wiki)
then people will do as they please anyway - see rel="hub",
rev="canonical", etc.

> (which IANA likes to see in registries, AIUI, for paper trail etc).

Would it be possible then to support multiple references so that people can
see at a glance that a given relation is implemented as described in
multiple formats (rather than just the first format that happened to
register it)? May well not be worth the maintenance effort.

> formats, but that's an artefact of history, not the direction we'll move in
> going forward.

That being the case would it be worth proactively populating the registry
with common/obvious relations with a view to avoiding e.g. this "monitor" vs
"hub" duplication (which is presumably burnt into various implementations on
both sides)?

I'm specifically thinking here about a thread from a few months ago in which
we discussed different types of references to resources, with a view to
getting relations like 'canonical', 'latest', 'permalink' and 'shortlink'
into the registry. Perhaps a separate I-D is the best way to achieve this,

Sam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 19:19:29 -0700

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Sam Johnston
> Sent: Wednesday, September 16, 2009 2:47 AM
> To: Mark Nottingham
> Cc: atom-syntax Syntax; Hadrien Gardeur; HTTP Working Group; apps-
> [email-masked]
> Subject: Re: Input on request for link relation
> 
> 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.
> 
> Perhaps not, and there could well be some delay in acceptance if
> committees are involved. My worry is that if we don't streamline our
> processes as much as possible (see Ian's suggestion about IANA
> maintaining a RelExtensions style wiki) then people will do as they
> please anyway - see rel="hub", rev="canonical", etc.

I am sure there will be those that even something as "simple" as wiki will be deemed too much effort. The delay is usually not with the registry but with getting consensus. The longer it take to build consensus is usually an indication of issues with the request to take a common term and assign it to a particular use case.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2009 16:26:11 +1000

> please anyway - see rel="hub", rev="canonical", etc.

Interesting examples; the "hub" people are actively engaging  
(finally), and I've already talked to some of the "canonical" folks  
about doing an I-D once the Link draft is an RFC.

> Would it be possible then to support multiple references so that  
> people can see at a glance that a given relation is implemented as  
> described in multiple formats (rather than just the first format  
> that happened to register it)? May well not be worth the maintenance  
> effort.

How about adding a new field for references to more information about  
how a relation is used in a particular context (scoped by context  
media type)?

E.g.,

References regarding use in specific contexts:
     text/html: [HTML5]
     application/atom+xml: [RFC4287]

One concern here is that there are going to be questions about  
authority; while it's fine for the HTML5 crowd to dictate what happens  
when you see a particular relation in an HTML context, what happens  
when someone comes along and defines a spec for a media type they  
don't own? We'd need some additional guidance about amending  
registrations, I think, which is doable, but it'll make things more  
complex.

What do people think about this generally? Ian, would this help you at  
all?

We'd still need a generic 'reference' field for the defining document  
of the relation itself, but in some cases the current references would  
change to be context references; e.g.,

             Relation Name: chapter
             Description: Refers to a chapter in a collection of  
resources.
             Reference: [this specification]
             References regarding use in specific contexts:
                   text/html: [W3C.REC-html401-19991224]

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 27 Sep 2009 10:18:52 +1000

On 24/09/2009, at 7:37 PM, Ian Hickson wrote:
>
> It would certainly be an improvement, though I'm still unconvinced  
> that we
> want different definitions for the same link type for different MIME
> types. Difference conformance classes, sure, but that's another issue.

Yes, that's the tricky part; there would be a tendency to define  
different meanings for different mime types, no matter how clearly  
it's stated that the additional information was restricted to the  
interpretation/implementation of the relations.