W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Input on request for link relation

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Date: Fri, 11 Sep 2009 12:01:37 +0000
Message-ID: <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com>
To: Sam Johnston <samj@samj.net>
Cc: Jan Algermissen <algermissen1971@mac.com>, jpanzer@acm.org, Lisa Dusseault <lisa.dusseault@gmail.com>, Atom-Syntax Syntax <atom-syntax@imc.org>, ietf-http-wg@w3.org
> 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.

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

> In terms of the relation, I think the description could be improved by
> dropping references to entries, Atom and RSS. It is conceivable for example
> that someone would want to be notified of an update to an HTML page (I'm
> thinking about this currently for status updates to HTML renderings of
> virtual machine resources) or indeed some other arbitrary resource. If we
> [continue to] allow relations to be bound to protocols in spite of the
> availability of content types and/or URI relations which are fit for the
> purpose we're going to back ourselves into a corner before we know it.

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.

Received on Friday, 11 September 2009 13:58:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC