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

Re: Input on request for link relation

From: Sam Johnston <samj@samj.net>
Date: Fri, 13 Nov 2009 01:28:49 +0100
Message-ID: <21606dcf0911121628o20229c2ao3f73648941381ef2@mail.gmail.com>
To: Bill de hOra <bill@dehora.net>
Cc: Joe Gregorio <joe@bitworking.org>, Mark Nottingham <mnot@mnot.net>, Atom-Syntax Syntax <atom-syntax@imc.org>, Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, Ian Hickson <ian@hixie.ch>, HTTP Working Group <ietf-http-wg@w3.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>

On Fri, Nov 13, 2009 at 12:00 AM, Bill de hOra <bill@dehora.net> wrote:

> > (opaque URI-based) rel so I have proposed class="action" be added for
> <link rel="stop@occi"
> where "occi" is registered as for use by occi.
> IOW allow the link registry to define rel scopes. The url or clash thing
> sucks and I don't want someone rolling up with a curies/qnames or some other
> XML macrocrap proposal for Atom.

Thanks for the feedback - this is an interesting idea, however it's not
immediately clear to me how this helps us as one of our main motivations is
that others can create their own actions without bothering us or having to
be registered.

Basically we'd be trading one opaque identifier that doesn't need to be
registered for a shorter one that does and unless we were to accept
petitions from the public it would still not be possible to identify which
relations are "actions" anyway (consider "stop@occi" vs "quiesce@vendor").
The use case is the client saying "ok all these things are actions so even
if I don't understand what "quiesce" means I can still show a button to the
user in the right place".

A reversed, dotted domain format ala "org.occi-wg.action.stop" was something
else we considered but it too would not enjoy backwards compatibility with
existing implementations. It would however provide a simple solution to the
registry "problem" and could be easily differentiated from "short" relations
by the presence of "." and URIs by ":" (or some other regexps). That is to
say, it's compatible with what we have today, infinitely scalable,
distributed, concise, basically everything you want in an identifier.


>  Sam Johnston wrote:
>> Another requirement I've stumbled on is the ability to group links.
>> For OCCI for example we want to give users the ability to create their
>> own actions (eg start, stop, restart) which will be advertised in the
>> HTTP headers and/or HTML HEAD. Currently each action has it's own
>> (opaque URI-based) rel so I have proposed class="action" be added for
>> grouping. Alternatively we could do rel="[http://purl.org/occi/]
>> action" and refine the action with one or more custom attributes (type
>> is not really appropriate here, nor when advertising protocol
>> endpoints like SSH and RDP which is anoter problem we ran into).
>> Pagination (eg first, last, next, previous) is another potentially
>> interesting group. Though the semantics are mostly predefined one
>> could envisage links like "next 100", "next 1000".
>> Sam on iPhone
>> On 12/11/2009, at 7:18, Joe Gregorio <joe@bitworking.org> wrote:
>>  On Thu, Sep 17, 2009 at 5:26 PM, Mark Nottingham <mnot@mnot.net>
>>> wrote:
>>>> On 16/09/2009, at 7:46 PM, Sam Johnston wrote:
>>>>> 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]
>>>>  Yes, that sounds like a great idea. And vaguely familiar:
>>>  http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/
>>> 0699.html
>>>  Thanks,
>>>  -joe
Received on Friday, 13 November 2009 00:29:27 UTC

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