Subject: Link: grandfathered format-specific registered relations

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Aug 2009 10:44:06 +1000

I'm thinking that the following registered relations are in fact  
specific to one format or application, and this should be noted in  
their registrations.

current
edit
edit-media
enclosure
next-archive
prev-archive
replies
service

Comments?

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

---

From: Sam Johnston <[email-masked]>
Date: Thu, 20 Aug 2009 09:06:29 +0200

On Thu, Aug 20, 2009 at 2:44 AM, Mark Nottingham <[email-masked]> wrote:

> I'm thinking that the following registered relations are in fact specific
> to one format or application, and this should be noted in their
> registrations.
>
> current
> edit
> edit-media
> enclosure
> next-archive
> prev-archive
> replies
> service
>
> Comments?
>

I would have thought that the relations should be generic and the types
specific.

Sam

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Aug 2009 15:06:42 +1000

They should, but because these were registered previously, they aren't.

On 20/08/2009, at 5:06 PM, Sam Johnston wrote:

> I would have thought that the relations should be generic and the  
> types specific.
>
> Sam
>

---

From: Nicolas Alvarez <[email-masked]>
Date: Fri, 21 Aug 2009 21:45:06 -0300

> specific to one format or application, and this should be noted in

Wondering... As Sam says, relations should be generic and types specific.
That makes sense for GETtable URis, for example, rel=replies is generic and
type would say whether it's a RSS feed or an HTML page with replies.

However, what about POSTable URIs? The type attribute, as I understand it,
says what data you'll get back, not what data to send. How can you say that
a rel=edit link is a URI where you can POST a specific data type, maybe
getting text/html in the response?

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Aug 2009 11:44:07 +1000

I'm not sure what this has to do with my message.

While we could try to optimistically define the semantics of each of  
these in a generic fashion, it's likely to be a shot in the dark --  
i.e., there is as of yet no proven value to more than one application  
in these, just speculation that it may be later.

To reiterate - registered relations are supposed to be generic, while  
extension relations have no such constraint. However, the registry  
currently has some specific relations in, because they're already there.

As such, the proposal is to recognise this in the registry.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Aug 2009 11:46:56 +1000

So what does 'edit-media' mean when it's used with a non-Atom relation?

On 22/08/2009, at 11:44 AM, Roy T. Fielding wrote:

> On Aug 20, 2009, at 10:06 PM, Mark Nottingham wrote:
>
> I don't follow that.  There are no media-specific relations.  There
> are some very specific relations defined by some media types, but
> there is absolutely nothing preventing those relations being used
> outside those types to mean exactly the same thing.
>
> ....Roy
>
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 21 Aug 2009 19:06:54 -0700

> So what does 'edit-media' mean when it's used with a non-Atom  

You mean "when it's used within a non-Atom format document, right?
It means the same thing it does within an Atom format document.

Whether or not that meaning is useful is presumably decided by the
person who stuck it there.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 21 Aug 2009 18:44:26 -0700

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Aug 2009 11:28:56 +1000

> You mean "when it's used within a non-Atom format document, right?

Actually, I meant when it points to a non-Atom formatted document, but  
yes, the context may have some bearing on it as well... (there are  
likely some interesting questions buried in that distinction, which  
I'll ignore for the moment).

> person who stuck it there.

Right. The problem I see is that "means the same thing" is fine in  
theory, but in practicality, people aren't going to know what a  
service relation for an HTML document is (for example).

In the end, I don't suppose it matters; because these relations have  
doubtful utility for other applications, they're likely to be ignored  
outside of those realms.

I'd thought it would be nice to advise the unwary that their semantics  
are somewhat cloudy outside of their intended application domains.  
However, it doesn't look like anyone else supports doing this.

Cheers,

---

From: Sam Johnston <[email-masked]>
Date: Sun, 30 Aug 2009 08:47:20 +0200

> It means the same thing it does within an Atom format document.

RFC 5023 defines edit-media as "an IRI that can be used to modify a[n
associated] Media Resource" - there is nothing Atom-specific about that and
as a generic relation it seems like something that could be useful for OCCI
too (or more importantly something I'd have to redefine for OCCI if Atom
were able to claim a monopoly on this relation - e.g. occi-edit-media?).
Similarly, I'm not the only one thinking about what JSONpub might look
like<http://twitter.com/pkeane/status/1941800604>,
in which case we would need to create another [set of] relation(s) for it.

> person who stuck it there.

Agreed - I don't see much risk in taking context into account (e.g. the
format of the document you're parsing) when deciphering relations.

We could even pre-define some relations of our own with a view to focusing
future development efforts - for example, 'start' and 'stop' relations are
intensely interesting for our WG but could be useful for the web of things
too (imagine turning on and off machines - even simple ones like light
bulbs) - and the semantics are obvious. I'd much rather see sensible generic
terms adopted than things like 'light-on' and 'light-off'.

Sam