Subject: [apps-discuss] NEW RELATION: 'action' version update

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 27 Aug 2013 13:03:00 +0400

Hi All,

I've updated the "action" link relation type spec[1] based on initial feedback. 

As far as initial reactions were very controversial and raised a lot of issues i tried to address all of them and entirely changed the spec.

==================================================
When included in a response, the "action" link relation indicates a
target resource that is responsible for performing action which MAY:

- Affect state of the context resource; or
- Initiate process.

The "action" link relation type can be used to indicate the
availability of actions supported by the target resource. Examples
of such actions include:

-  Enable/Disable
-  Publish/Unpublish
-  Start/Stop

The "action" link relation type doesn't convey any semantics other
than that an indicated resources represent machine readable
description of a particular action and representation SHOULD contain
all necessary details such as: request method, action URI and other
related details to enable agents to be able to construct requests
without relying on out-of-band information.

Exact type of action SHOULD be indicated through the "action-type"
link-extension value as per [RFC5988] and for maintaining shared
understanding of action types current specification introduces the
registry of actions with initial values of widely accepted and well
understood action types.

For example, if a resource represents a service, that same
representation may include links to resources that represent actions 
supported by the service:

Link: </restart-action>; rel="action"; action-type="restart"
Link: </stop-action>; rel="action"; action-type="stop"

==================================================

1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01 

Cheers,
ioseb

-- 
Ioseb Dzmanashvili
AzRy LLC
Software Architect
#8, Chachava str. Tbilisi, 0159, Georgia
Mobile: +(995) 99753388
azry.com
github.com/ioseb
twitter.com/iosebi

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Aug 2013 12:15:18 +0200

On 2013-08-27 11:03, Ioseb Dzmanashvili wrote:
> ...

It seems that you are just adding an indirection mechanism. Why is that 
necessary?

Best regards, Julian

---

From: Mark Baker <[email-masked]>
Date: Tue, 27 Aug 2013 09:16:00 -0400

necessary?

Agreed. The action-types should be registered as the relations.

Also, you might consider reusing the good work of the folks behind
Schema.org;

http://schema.org/Action

---

From: James M Snell <[email-masked]>
Date: Tue, 27 Aug 2013 08:38:48 -0700

> Also, you might consider reusing the good work of the folks behind

Not to mention activitystrea.ms where many of these verbs already
exist (and could easily be used as link relations themselves).

  Link: <start-action>; rel="start"
  Link: <restart-action>; rel="restart"

Would be generally easier overall.

- James

>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 27 Aug 2013 23:40:05 +0400

Hi Julian,

Thanks for response! 

> It seems that you are just adding an indirection mechanism. Why is that 

With indirection mechanism i'm trying to solve issues raised around initial version of the spec[1]. There were several issues:

1. The "action" link relation type doesn't have enough semantics and automated agents can not follow such links if there are several actions included in a representation. With the "action-type" link extension + registry of predefined action types agents can distinguish actions from each other. 

2. Initial spec stated that if the "action" link exists in representation, only thing agents should do is to send empty POST request to the target in order to perform action. This approach was considered as an anti pattern(RPCish and non RESTful). With having the "action-type" agents can:

a) distinguish action links from each other; 
b) if necessary dereference the target to obtain instructions for constructing non empty POST/PUT requests;
c) send properly constructed request back to the target; and
d) it makes possible for servers to dictate structure of the request according to there own needs.

Main purpose of the "action" link relation type is to define semantics of particular class of links - actions. This eliminates the need to redefine notion of "action" for each link relation type which may be qualified as action link. The "action-type" is just for naming actions and is particularly useful for automated agents not necessarily for human interaction oriented agents.

Having action type registry is important for maintaining shared understanding of particular action types. For example "reset" or "publish" verbs do not need to be redefined from application to application. I also believe that it is not efficient(or feasible) to register all possible actions as link relations.

1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 
2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01
Cheers, 
ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 27 Aug 2013 23:46:12 +0400

Hi James,

Thanks for response!  

On Tuesday, August 27, 2013 at 7:38 PM, James M Snell wrote:

> On Tue, Aug 27, 2013 at 6:16 AM, Mark Baker <[email-masked] (mailto:[email-masked])> wrote:
> > 
> > On 2013-08-27 6:15 AM, "Julian Reschke" <[email-masked] (mailto:[email-masked])> wrote:
> > Schema.org (http://Schema.org);
> > 
> > http://schema.org/Action
> 
> Not to mention activitystrea.ms (http://activitystrea.ms) where many of these verbs already
It is not about "start" or "restart" link relation types, i included these as examples. As i already explained in response to Julian, it is about to define what the "action" itself is and make it reusable for particular class of links without the need to redefine meaning of "action" each time. Action type registry is for maintaining minimal shared understanding and is actually only useful for m2m interaction scenarios.
> > [email-masked] (mailto:[email-masked])
> link-relations mailing list
> [email-masked] (mailto:[email-masked])
> https://www.ietf.org/mailman/listinfo/link-relations

Cheers,
ioseb

---

From: mike amundsen <[email-masked]>
Date: Tue, 27 Aug 2013 15:57:46 -0400

Ioseb:

it is not clear to me why: <link rel="action;action-type='edit'" href="..."
/>
is preferable to: <link rel="edit" href="..." />

talk me down ;)
mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili <
[email-masked]> wrote:

> > > As far as initial reactions were very controversial and raised a lot
> of issues i tried to address all of them and entirely changed the spec.
> > >
> With indirection mechanism i'm trying to solve issues raised around
> initial version of the spec[1]. There were several issues:
>
> 1. The "action" link relation type doesn't have enough semantics and
> automated agents can not follow such links if there are several actions
> included in a representation. With the "action-type" link extension +
> registry of predefined action types agents can distinguish actions from
> each other.
>
> 2. Initial spec stated that if the "action" link exists in representation,
> only thing agents should do is to send empty POST request to the target in
> order to perform action. This approach was considered as an anti
> pattern(RPCish and non RESTful). With having the "action-type" agents can:
>
> b) if necessary dereference the target to obtain instructions for
> constructing non empty POST/PUT requests;
> Main purpose of the "action" link relation type is to define semantics of
> particular class of links - actions. This eliminates the need to redefine
> notion of "action" for each link relation type which may be qualified as
> action link. The "action-type" is just for naming actions and is
> particularly useful for automated agents not necessarily for human
> interaction oriented agents.
>
> Having action type registry is important for maintaining shared
> understanding of particular action types. For example "reset" or "publish"
> verbs do not need to be redefined from application to application. I also
> believe that it is not efficient(or feasible) to register all possible
> actions as link relations.
>
> 1.
> http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00
> 2.
> http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01
> >
> > Best regards, Julian
> Cheers,
> ioseb
>
> [email-masked]

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 03:51:03 +0400

Hi Mike,

Thanks for the question!  

On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:

> Ioseb:
>  
> it is not clear to me why: <link rel="action;action-type='edit'" href="..." />
let me try ;)

Question is not about why: Link: <…>; rel="action"; action-type="edit" is preferable to: Link: <…>; rel="edit".

Of course i'd choose rel="run-forest-run" if there is a registered link relation type, but:

1. The "action" link relation is generic enough, has well understood meaning and is useful on its own especially for human oriented agents.
2. The "action-type" optional attribute may be used for specifying exact meaning of actions and this makes action links more useful for m2m scenarios.

Now consider this link:

Link: </suspend-action>; rel="action"; action-type="suspend"; title="Suspend"

What it says?

1. it is an action
2. target resource represents description of the action which contains: request method, submit URI, definition of action, other details etc
3. agent can look inside "action-type" to determine whether it needs this action type or not
4. agent can dereference it, construct request and send it to server

now if we add more actions:

Link: </suspend-action>; rel="action"; action-type="suspend"; title="Suspend"
Link: </restart-action>; rel="action"; action-type="restart"; title="Restart"

Link: </stop-action>; rel="action"; action-type="stop"; title="Stop"

#1, #2, #3 and #4 will be true for all of them without exceptions.

Now consider that representation containing these links is used by GUI agent, in this case even "action-type" is not necessary at all and agent can rely on user's choice. Agent only needs to know that:

1. link is an action(and this question is explicitly answered)
2. if user choose one agent needs just to dereference indicated URI
3. construct request  
4. send request to server
5. show results to user

All of these will remain true for any action type.

I'm not sure if i talked you down, but i believe "action" relation type is useful and not because it is better(or simpler) compared to rel="edit" for example.  

P.S.
I was talking about 01 version of spec. 00 is a different story.

Cheers,
ioseb
> On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > Hi Julian,
> >  
> > Thanks for response!
> >  
> > [email-masked] (mailto:[email-masked]) (mailto:[email-masked])

---

From: mike amundsen <[email-masked]>
Date: Tue, 27 Aug 2013 21:26:25 -0400

OK, from your response i get the following:

1) you want to support a pattern where machine-readable state transition
instructions appear at the end of some URL.
2) you want to indicate those instructions are available by marking the URL
w/ the string literal "action" (via rel in your illustrations)
3) you want to indicate the reason for using these instructions w/ an
"action-type" string (via a link-rel param in your illustrations)

that's it. nothing else.

do i have this correct?

mamund
+1.859.757.1449
skype: mca.amundsen

On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili <
[email-masked]> wrote:

> 1. The "action" link relation is generic enough, has well understood
> meaning and is useful on its own especially for human oriented agents.
> 2. The "action-type" optional attribute may be used for specifying exact
> meaning of actions and this makes action links more useful for m2m
> scenarios.
>
> Now consider this link:
>
> 2. target resource represents description of the action which contains:
> request method, submit URI, definition of action, other details etc
> Now consider that representation containing these links is used by GUI
> agent, in this case even "action-type" is not necessary at all and agent
> can rely on user's choice. Agent only needs to know that:
>
> I'm not sure if i talked you down, but i believe "action" relation type is
> useful and not because it is better(or simpler) compared to rel="edit" for
> example.
>
> 1.
> [email-masked] (mailto:[email-masked])
> (mailto:[email-masked])> wrote:
> > > Hi Julian,
> > >
> > > Thanks for response!
> > >
> > > > > As far as initial reactions were very controversial and raised a
> lot of issues i tried to address all of them and entirely changed the spec.
> > > > >
> > > 2. Initial spec stated that if the "action" link exists in
> representation, only thing agents should do is to send empty POST request
> to the target in order to perform action. This approach was considered as
> an anti pattern(RPCish and non RESTful). With having the "action-type"
> agents can:
> > >
> > > Main purpose of the "action" link relation type is to define semantics
> of particular class of links - actions. This eliminates the need to
> redefine notion of "action" for each link relation type which may be
> qualified as action link. The "action-type" is just for naming actions and
> is particularly useful for automated agents not necessarily for human

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 11:35:03 +0400

Mike,

On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote:

> 1) you want to support a pattern where machine-readable state transition instructions appear at the end of some URL.  
> 2) you want to indicate those instructions are available by marking the URL w/ the string literal "action" (via rel in your illustrations)
> 3) you want to indicate the reason for using these instructions w/ an "action-type" string (via a link-rel param in your illustrations)
>  
> that's it. nothing else.  
>  
> do i have this correct?  
>  

Exactly! That's it and nothing else.  

Cheers,
ioseb
  
> On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> > Hi Mike,
> >  
> > Thanks for the question!
> >  
> > > +1.859.757.1449 (tel:%2B1.859.757.1449)
> > > skype: mca.amundsen
> > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > > > Hi Julian,
> > > >  
> > > > Thanks for response!
> > > >  
> > > > [email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 12:04:48 +0400

Hi Mike,

On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote:

>  
> On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" <[email-masked] (mailto:[email-masked])> wrote:
> >  
> > Hi Mike,
> >  
> > Thanks for the question!
> >  
> Hey Ioseb, isn't this what extension relations are for?

@mamund perfectly summarised major goals of the spec so i'm copying it here:

1) you want to support a *pattern* where machine-readable state transition instructions appear at the end of some URL.
2) you want to indicate those instructions are available by marking the URL w/ the string literal "action" (via rel in your illustrations)
3) you want to indicate the reason for using these instructions w/ an "action-type" string (via a link-rel param in your illustrations)

Additionally semantics of extension relations may vary from application to application. With the "action-type" optional attribute + registry of machine readable action type names i'm trying to address the issue of shared semantics and at the same time the "action" relation itself still remains useful for GUI scenarios without the "action-type" attribute.

Cheers,
ioseb
  
> M

---

From: mike amundsen <[email-masked]>
Date: Wed, 28 Aug 2013 10:33:38 -0400

Ioseb:

now that i understand your aim...

it seems the first item (support a pattern...) is the important one and the
other two are just means to that end.  so why is this a good approach?

1) why use the "action" rel PLUS a param ("start")? why not just use the
param ("start") as the rel?
2) why not use two values for the rel as in <LINK rel="action start" />?
3) why not use (as mike kelly suggests) an extension URI for the rel as in
<LINK rel="http://actions.io/start" ... />
4) why not use a unique element attribute/property such as <LINK
rel="action" reason="start" .../>?
5) why not use a unique document element/property such as <action
rel="start" href="..."/> or {"action": {"rel":"start", "href":"..."}}?

mamund
+1.859.757.1449
skype: mca.amundsen

On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili <
[email-masked]> wrote:

> > 2) you want to indicate those instructions are available by marking the
> URL w/ the string literal "action" (via rel in your illustrations)
> [email-masked] (mailto:[email-masked])> wrote:
> > > Hi Mike,
> > >
> > > Thanks for the question!
> > >
> > > 2. The "action-type" optional attribute may be used for specifying
> exact meaning of actions and this makes action links more useful for m2m
> scenarios.
> > >
> > > Now consider this link:
> > >
> > > 2. target resource represents description of the action which
> contains: request method, submit URI, definition of action, other details
> etc
> > > I'm not sure if i talked you down, but i believe "action" relation
> type is useful and not because it is better(or simpler) compared to
> rel="edit" for example.
> > >
> > > 1.
> (mailto:[email-masked]) (mailto:[email-masked])>
> wrote:
> > > > > Hi Julian,
> > > > >
> > > > > Thanks for response!
> > > > >
> > > > > > > As far as initial reactions were very controversial and raised
> a lot of issues i tried to address all of them and entirely changed the
> spec.
> > > > > > >
> > > > > With indirection mechanism i'm trying to solve issues raised
> around initial version of the spec[1]. There were several issues:
> > > > >
> > > > > 1. The "action" link relation type doesn't have enough semantics
> and automated agents can not follow such links if there are several actions
> > > > > Main purpose of the "action" link relation type is to define
> semantics of particular class of links - actions. This eliminates the need
> to redefine notion of "action" for each link relation type which may be
> > > > > [email-masked] (mailto:[email-masked]) (mailto:
> [email-masked]) (mailto:[email-masked])

---

From: James M Snell <[email-masked]>
Date: Wed, 28 Aug 2013 08:31:59 -0700

I'm still struggling to see the value of a generic "action" link
relation here. If I have a set of link relations that I happen to want
to mark as "action", I would prefer to eliminate the indirection and
simply "flag" the links, for instance:

Link: <restart-action>; rel="restart"; action

or in HTML

<link rel="restart" href="restart-action" class="action" /> or...
<link rel="restart" href="restart-action" action />

This approach would skip the additional registration mechanism for
action-type and would allow any link relation to potentially be marked
as an action... which seems appropriate.

- James

---

From: Mike Kelly <[email-masked]>
Date: Wed, 28 Aug 2013 08:45:08 +0100

Cheers,
M

---

From: Peter Williams <[email-masked]>
Date: Wed, 28 Aug 2013 08:14:59 -0600

I have a question about how this might affect future relationship
registrations. Consider the following scenario:

This proposal is adopted. As many apps begin exposing `start` links it
becomes obvious that start is a really common relationship. A proposal is
made to register a top level relationship `start`. (I am using `start`
purely for example purposes, this scenario works for any registered action
type.)

In this case would you expect the new relationship registration to be a)
rejected on the grounds that you can already accomplish it via the
action+action-type approach, b) accepted and the action relation updated to
declare the start action type archaic, c) accepted and action relation to
left as is, leaving it up to implementers to decide which approach to use
for themselves? (Or perhaps there is a option I have over looked.) What are
the implications for existing representations and consumers under that
outcome? What about new representations and consumers?

Cheers,
Peter
Hi Mike,

On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote:

>
> On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" <[email-masked](mailto:

1) you want to support a *pattern* where machine-readable state transition

Additionally semantics of extension relations may vary from application to
application. With the "action-type" optional attribute + registry of
machine readable action type names i'm trying to address the issue of
shared semantics and at the same time the "action" relation itself still
remains useful for GUI scenarios without the "action-type" attribute.

Cheers,
ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 20:41:10 +0400

Mike,

On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote:
> it seems the first item (support a pattern...) is the important one and the other two are just means to that end.
Actually as i see it #1 and #2 are of same importance.

> so why is this a good approach?
#1 and #2 still hold. As i already said #3 makes sense only for m2m scenarios and for GUI clients just knowing that a link is an action and how to treat such action links is enough.

What i'm trying to achieve with my proposal is to generalise meaning of action and make it consistent across different applications. Unfortunately i do not see(or know, or was not able to find) better approach yet but it is generic enough to solve whole class of problems at least on GUI level + partially for m2m cases with "action-type" attribute even if we throw action type registry idea away. If we simplify definition of the "action" relation type and say:

1. here is the "action" link
2. it points to a resource which describes the action
3. to perform an action fetch it construct request and send it back to server.
4. if you want to know what this particular action means:
4.1. look inside the "action-type" attribute if it presents; or
4.2. fetch the document and look inside it.

Is not it sufficient enough to cover whole class of problems in a consistent way which are clearly actions and not just related resources?

So here is my question: why is it bad?

> 1) why use the "action" rel PLUS a param ("start")? why not just use the param ("start") as the rel?
For several reasons:

1. there is no "start" relation yet.
2. it doesn't have explicit sign that it is an action.
3. there are much more actions which are not registered and also there is no guarantee that each newly registered relation(which can be qualified as action) will state that it is an action in a consistent way.
4. the pattern as you noticed is still important(IMHO)

> 2) why not use two values for the rel as in <LINK rel="action start" />?

It was suggested in the initial proposal though approach has drawbacks. if i use more rels? <LINK rel="action foo bar baz" /> how to distinguish "foo", "bar" and "baz" from each other? does it mean that my action now has triple meaning?
  
> 3) why not use (as mike kelly suggests) an extension URI for the rel as in <LINK rel="http://actions.io/start" ... />  
>  
> 4) why not use a unique element attribute/property such as <LINK rel="action" reason="start" .../>?
>  
>  

is it different from "action-type" attribute? or maybe problem is in a registry of action types?    

> 5) why not use a unique document element/property such as <action rel="start" href="..."/> or {"action": {"rel":"start", "href":"..."}}?  
Well, in custom media types i can do anything, though it doesn't make sense outside of particular format or domain. Otherwise it is ok and i use similar approach in practice.

Cheers,
ioseb

> On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > Mike,
> >  
> > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > > > Hi Mike,
> > > >  
> > > > Thanks for the question!
> > > >  
> > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449)
> > > > > skype: mca.amundsen
> > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > > > > > Hi Julian,
> > > > > >  
> > > > > > Thanks for response!
> > > > > >  
> > > > > > [email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 20:53:34 +0400

Hi Peter,

Thanks for feedback!  

On Wednesday, August 28, 2013 at 6:14 PM, Peter Williams wrote:

> I have a question about how this might affect future relationship registrations. Consider the following scenario:
> This proposal is adopted. As many apps begin exposing `start` links it becomes obvious that start is a really common relationship. A proposal is made to register a top level relationship `start`. (I am using `start` purely for example purposes, this scenario works for any registered action type.)
> In this case would you expect the new relationship registration to be a) rejected on the grounds that you can already accomplish it via the action+action-type approach, b) accepted and the action relation updated to declare the start action type archaic, c) accepted and action relation to left as is, leaving it up to implementers to decide which approach to use for themselves? (Or perhaps there is a option I have over looked.) What are the implications for existing representations and consumers under that outcome? What about new representations and consumers?

With my proposal i'm trying to solve the problem of particular class - actions. I want to have generalised approach which works from application to application without redefining a) notion of action; b) basic interaction model; and c) at least minimal shared understanding of particular kinds of actions.  

For the moment i'm not sure whether action type registry will be adopted at all and of course i do not see future implications clearly if the proposal will be accepted. What i can say for sure these cases can covered in the proposal, but it is not 100% clear for me yet. I believe further discussions will show how to eliminate such cases.

Cheers,
ioseb
> > On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" <[email-masked] (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > >  
> > > Hi Mike,
> > >  
> > > Thanks for the question!
> > >

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 21:00:20 +0400

Hi James,

> as an action... which seems appropriate.

How do i advertise this action "flag"? I can do it in media profile, i can do somewhere else. But how to do it outside of my domain? As I already said:  
I want to have generalised approach which works from application to application without redefining a) notion of action; b) basic interaction model; and c) at least minimal shared understanding of particular kinds of actions.

P.S.
Here are more details in response to Mike: http://www.ietf.org/mail-archive/web/link-relations/current/msg00554.html

Cheers,
ioseb

> <[email-masked] (mailto:[email-masked])> wrote:
> > Hi Mike,
> >

---

From: mike amundsen <[email-masked]>
Date: Wed, 28 Aug 2013 13:39:16 -0400

<snip>
So here is my question: why is it bad?
</snip>
1) creates a new registry for action-type instead of using existing
registry for rel (you point this out in the "there is not start relation
yet" reasoning)
2) ignores the use of link relation extension values already established in
RFC5988 (see Mike Kelly's question)
3) introduces confusion on whether @rel or "action-type" should be used
(see Peter Williams' question)
4) uses two values ("action" and "{reason}") where only one is needed
(srsly, a constant string AND a variable?)

IOW, you have two possible solutions already for the same outcome and are
not using them. you've been offered at least one issue
on conflicting implementation and at least one on overly-complex
implementation.

if you are so sure that this implementation detail is important to the
_results_ you want to achieve, then start today by doing it via link
extensions:
<LINK rel="http://actions.io/action;action-type="start" ... />

you can document and implement this today w/o any need to get an RFC
approved or get even buy-in from others. You can create your own registry
and open it up to others for adds/edits (similar to the way microformats
operates). You can build working implementations, write papers on it,
advocate for use in various forums, etc.

Over time you can monitor and record adoption, judge the up-take you get
and determine whether it proves to be a useful pattern. If it works well
and shows adoption, you'll see much less push-back from me (and, i suspect
others) and will be able to replace: <LINK rel="
http://actions.io/action;action-type="start" ... /> with <LINK
rel="action;action-type="start" ... /> and even allow existing
implementations to support both.

IOW, nothing is stopping you from implementing a compliant version of this
approach today and doing it in a way that would be compatible w/ adopting
your proposed approach once your approach is proven to be worthy of
recording as a standard.

finally, i'll say this:
<snip>
Actually as i see it #1 and #2 are of same importance.
</snip>
If the _method_ of achieving your results is non-negotiable, I have little
else to offer here.

Cheers.

mamund
+1.859.757.1449
skype: mca.amundsen

On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili <
[email-masked]> wrote:

> > it seems the first item (support a pattern...) is the important one and
> the other two are just means to that end.
> #1 and #2 still hold. As i already said #3 makes sense only for m2m
> scenarios and for GUI clients just knowing that a link is an action and how
> to treat such action links is enough.
>
> What i'm trying to achieve with my proposal is to generalise meaning of
> action and make it consistent across different applications. Unfortunately
> i do not see(or know, or was not able to find) better approach yet but it
> is generic enough to solve whole class of problems at least on GUI level +
> partially for m2m cases with "action-type" attribute even if we throw
> action type registry idea away. If we simplify definition of the "action"
> relation type and say:
>
> Is not it sufficient enough to cover whole class of problems in a
> consistent way which are clearly actions and not just related resources?
>
> 3. there are much more actions which are not registered and also there is
> no guarantee that each newly registered relation(which can be qualified as
> action) will state that it is an action in a consistent way.
> It was suggested in the initial proposal though approach has drawbacks. if
> i use more rels? <LINK rel="action foo bar baz" /> how to distinguish
> "foo", "bar" and "baz" from each other? does it mean that my action now has
> triple meaning?
>
> > 3) why not use (as mike kelly suggests) an extension URI for the rel as
> in <LINK rel="http://actions.io/start" ... />
> >
> Well, in custom media types i can do anything, though it doesn't make
> sense outside of particular format or domain. Otherwise it is ok and i use
> similar approach in practice.
>
> Cheers,
> ioseb
>
> >
> > mamund
> > +1.859.757.1449
> > skype: mca.amundsen
> > > > 1) you want to support a pattern where machine-readable state
> transition instructions appear at the end of some URL.
> > > > 2) you want to indicate those instructions are available by marking
> the URL w/ the string literal "action" (via rel in your illustrations)
> > > > 3) you want to indicate the reason for using these instructions w/
> an "action-type" string (via a link-rel param in your illustrations)
> > > >
> > > > that's it. nothing else.
> > > >
> > > > do i have this correct?
> > >
> > > > > Question is not about why: Link: <…>; rel="action";
> action-type="edit" is preferable to: Link: <…>; rel="edit".
> > > > >
> > > > > 1. The "action" link relation is generic enough, has well
> understood meaning and is useful on its own especially for human oriented
> agents.
> > > > > Now consider that representation containing these links is used by
> GUI agent, in this case even "action-type" is not necessary at all and
> agent can rely on user's choice. Agent only needs to know that:
> > > > >
> (mailto:[email-masked]) (mailto:[email-masked])
> > > > > > > > > As far as initial reactions were very controversial and
> raised a lot of issues i tried to address all of them and entirely changed
> the spec.
> > > > > > > > >
> > > > > > > 1. The "action" link relation type doesn't have enough
> semantics and automated agents can not follow such links if there are
> several actions included in a representation. With the "action-type" link
> extension + registry of predefined action types agents can distinguish
> actions from each other.
> > > > > > >
> > > > > > > b) if necessary dereference the target to obtain instructions
> for constructing non empty POST/PUT requests;
> > > > > > > Having action type registry is important for maintaining
> shared understanding of particular action types. For example "reset" or
> "publish" verbs do not need to be redefined from application to
> application. I also believe that it is not efficient(or feasible) to
> register all possible actions as link relations.
> > > > > > >
> > > > > > > 1.
> (mailto:[email-masked]) (mailto:[email-masked]) (mailto:

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 28 Aug 2013 23:38:01 +0400

Mike,

On Wednesday, August 28, 2013 at 9:39 PM, mike amundsen wrote:

> 1) creates a new registry for action-type instead of using existing registry for rel (you point this out in the "there is not start relation yet" reasoning)
> 2) ignores the use of link relation extension values already established in RFC5988 (see Mike Kelly's question)
> 3) introduces confusion on whether @rel or "action-type" should be used (see Peter Williams' question)
> 4) uses two values ("action" and "{reason}") where only one is needed (srsly, a constant string AND a variable?)  
>  
> IOW, you have two possible solutions already for the same outcome and are not using them. you've been offered at least one issue on conflicting implementation and at least one on overly-complex implementation.  
>  
> if you are so sure that this implementation detail is important to the _results_ you want to achieve, then start today by doing it via link extensions:  
> you can document and implement this today w/o any need to get an RFC approved or get even buy-in from others. You can create your own registry and open it up to others for adds/edits (similar to the way microformats operates). You can build working implementations, write papers on it, advocate for use in various forums, etc.  
>  
I'd prefer to avoid this, i do not have enough resources to publicly maintain such registry ;-)
  
> Over time you can monitor and record adoption, judge the up-take you get and determine whether it proves to be a useful pattern. If it works well and shows adoption, you'll see much less push-back from me (and, i suspect others) and will be able to replace: <LINK rel="http://actions.io/action;action-type="start" ... /> with <LINK rel="action;action-type="start" ... /> and even allow existing implementations to support both.  
>  
> IOW, nothing is stopping you from implementing a compliant version of this approach today and doing it in a way that would be compatible w/ adopting your proposed approach once your approach is proven to be worthy of recording as a standard.  
>  
> finally, i'll say this:
> <snip>
> If the _method_ of achieving your results is non-negotiable, I have little else to offer here
>  

All clear.

As a conclusion:

1. Having the generic "action" relation is worthless, at list as of 00 and 01 proposals. At least i need to find better way to make it acceptable.
2. Action type registry complicates things(and i agree).
3. One possible way is to maintain separate registry(out of IETF) which is not feasible for me.
4. Most realistic is to register top level action link rels and i've several such relations:

- start: start service or process
- stop: stop service or process
- restart: restart service or process
- suspend: suspend service or process
- reset: reset service or process to its initial state

- publish: change state of the resource to published
- unpublish: change state of the resource to unpublished
- archive: change state of the resource to archived
- unarchive: change state of the resource to unarchived

- enable: change state of the resource to enabled
- disable: change state of the resource to disabled

These are actions i used frequently in various applications. Do you think it is reasonable to register all of these as link relations?

Folks? What do you think?

Cheers,
ioseb
  
> .  
> On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> > Mike,
> >  
> > > On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > > > Mike,
> > > >  
> > > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > > > > > Hi Mike,
> > > > > >  
> > > > > > Thanks for the question!
> > > > > >  
> > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449)
> > > > > > > skype: mca.amundsen
> > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])> wrote:
> > > > > > > > Hi Julian,
> > > > > > > >  
> > > > > > > > Thanks for response!
> > > > > > > >  
> > > > > > > > [email-masked] (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked]) (mailto:[email-masked])

---

From: mike amundsen <[email-masked]>
Date: Wed, 28 Aug 2013 16:02:19 -0400

If you want to author and register new link relation values i have a couple
recommendations:

1) check out the microformats existing rel values page[1] along with the
usual IANA Link Relations page[2]. And the Dublin Core page has some good
stuff, too[3]. these will give you an idea of what's already out there and
some sense of what is in use. Peeking at Schema.org[4] and Activity
Streams[5] may help, but i've not done that much lately.

2) when crafting link rel values, i got good advice (I think it was from
JulianR?) to cast the definitions as "relations" not just "verbs" or
"nouns." for example:
"The link relation {value} identifies a target resource that represents {a
concept}." There are variations, but you'll get the idea.

3) once you have solid defs/values and documentation, i'd post that
publicly as a set and ask for feedback (here is a great place to start)

4) once you feel that the defs and values are solid, i suggest posting them
to the microformats wiki first. they are open to edits and also very quick
to provide feedback. i've had a good experience there.

5) once you have entries in the microformats list, you're more likely to be
able (IMO) to translate late that same set of des/values into something
that passes muster as an Informational RFC.

Of course, you can start using the values now (and getting others to do the
same) by relying on the Link Extension rules from 5988[6]. Watching that
unfold will give you and idea on the usefulness/popularity of your proposed
values.

Finally, i had some (old) random notes on my early work learning about
Link-Rel-Values[7] that might still contain some value. Feel free to poke
around there.

Hope this helps.

[1] http://microformats.org/wiki/existing-rel-values
[2] http://www.iana.org/assignments/link-relations/link-relations.xml
[3] http://dublincore.org/documents/dc-html/
[4] http://schema.org/
[5] http://activitystrea.ms/
[6] http://tools.ietf.org/html/rfc5988#section-4.2
[7] http://amundsen.com/media-types/linkrelations/

mamund
+1.859.757.1449
skype: mca.amundsen

On Wed, Aug 28, 2013 at 3:38 PM, Ioseb Dzmanashvili <
[email-masked]> wrote:

> > IOW, you have two possible solutions already for the same outcome and
> are not using them. you've been offered at least one issue on conflicting
> implementation and at least one on overly-complex implementation.
> >
> > IOW, nothing is stopping you from implementing a compliant version of
> this approach today and doing it in a way that would be compatible w/
> adopting your proposed approach once your approach is proven to be worthy
> of recording as a standard.
> >
> > finally, i'll say this:
> > <snip>
> 1. Having the generic "action" relation is worthless, at list as of 00 and
> 01 proposals. At least i need to find better way to make it acceptable.
> These are actions i used frequently in various applications. Do you think
> it is reasonable to register all of these as link relations?
>
> > > > it seems the first item (support a pattern...) is the important one
> and the other two are just means to that end.
> > > What i'm trying to achieve with my proposal is to generalise meaning
> of action and make it consistent across different applications.
> Unfortunately i do not see(or know, or was not able to find) better
> approach yet but it is generic enough to solve whole class of problems at
> least on GUI level + partially for m2m cases with "action-type" attribute
> even if we throw action type registry idea away. If we simplify definition
> of the "action" relation type and say:
> > >
> > > 3. there are much more actions which are not registered and also there
> is no guarantee that each newly registered relation(which can be qualified
> as action) will state that it is an action in a consistent way.
> > > It was suggested in the initial proposal though approach has
> drawbacks. if i use more rels? <LINK rel="action foo bar baz" /> how to
> distinguish "foo", "bar" and "baz" from each other? does it mean that my
> action now has triple meaning?
> > >
> > > > 3) why not use (as mike kelly suggests) an extension URI for the rel
> as in <LINK rel="http://actions.io/start" ... />
> > > >
> > > > > > 2) you want to indicate those instructions are available by
> marking the URL w/ the string literal "action" (via rel in your
> illustrations)
> > > > > > 3) you want to indicate the reason for using these instructions
> w/ an "action-type" string (via a link-rel param in your illustrations)
> > > > > >
> > > > > > that's it. nothing else.
> > > > > >
> > > > > > do i have this correct?
> > > > >
> > > > > > > > it is not clear to me why: <link
> rel="action;action-type='edit'" href="..." />
> > > > > > > 2. The "action-type" optional attribute may be used for
> specifying exact meaning of actions and this makes action links more useful
> for m2m scenarios.
> > > > > > >
> > > > > > > Now consider this link:
> > > > > > >
> > > > > > > Now consider that representation containing these links is
> used by GUI agent, in this case even "action-type" is not necessary at all
> and agent can rely on user's choice. Agent only needs to know that:
> > > > > > >
> > > > > > > I'm not sure if i talked you down, but i believe "action"
> relation type is useful and not because it is better(or simpler) compared
> to rel="edit" for example.
> > > > > > >
> > > > > > > 1.
> (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449)
> > > > > > > > skype: mca.amundsen
> > > > > > > > > > > As far as initial reactions were very controversial
> and raised a lot of issues i tried to address all of them and entirely
> changed the spec.
> > > > > > > > > > >
> > > > > > > > > With indirection mechanism i'm trying to solve issues
> raised around initial version of the spec[1]. There were several issues:
> > > > > > > > >
> > > > > > > > > b) if necessary dereference the target to obtain
> instructions for constructing non empty POST/PUT requests;
> > > > > > > > > d) it makes possible for servers to dictate structure of
> the request according to there own needs.
> > > > > > > > >
> > > > > > > > > Main purpose of the "action" link relation type is to
> define semantics of particular class of links - actions. This eliminates
> the need to redefine notion of "action" for each link relation type which
> may be qualified as action link. The "action-type" is just for naming
> actions and is particularly useful for automated agents not necessarily for
> human interaction oriented agents.
> > > > > > > > >
> [email-masked]) (mailto:[email-masked]) (mailto:
> [email-masked])

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 28 Aug 2013 22:27:24 +0200

On 28.08.2013, at 22:02, mike amundsen <[email-masked]> wrote:

> 2) when crafting link rel values, i got good advice (I think it was from JulianR?) to cast the definitions as "relations" not just "verbs" or "nouns." for example:
> "The link relation {value} identifies a target resource that represents {a concept}." There are variations, but you'll get the idea.

Yes. And do not let AtomPub's 'edit' fool you - it is just a bad choice. 'Edit' should have been sth like 'source' because what edit identifies is the one entry you need to direct requests to that intend to change the entry - (as opposed to the member-entries that represent that 'edit'-entry in individual collections.

IOW, you do not need a 'delete' and an 'edit' entry, just a 'source' entry and then you go there to PUT or DELETE.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 28 Aug 2013 22:49:13 +0200

> 1. Having the generic "action" relation is worthless, at list as of 00 and 01 proposals. At least i need to find better way to make it acceptable.

Hmm, I recall trying to tell you that in 00 ?

> - reset: reset service or process to its initial state

I'd say this is a domain (sending controll messages to control some 'thing') where REST isn't a particulary good fit. These operations expose a lot of implementation details - something that REST aims to hide. Or, IOW, using REST to design a control interface will not make you and the RESTafarians happy at the same time :-)

Suggestions:

- Build an unRESTful HTTP interface to avoid now uncool RPC solutions :-)  You know the story .... POST /jobs/start
 (Quite some things out there have such APIs, e.g. App servers, app engines,..)

- Hide the implementation details and think more in terms of what the client wants (I mean, who cares whether there is a job and that that can be suspended? Why would a service let a client start/stop/suspend anything it controls itself? IOW, talk about your domain, not the implementation

- Use a sort-of-restful solution by changing state of a status resource :

PUT /jobs/67/mode

<stoped/>

- or create a resource that the service provides for clients to change it's own internals vi an indirection. Much like you can edit a crontab, but not send a command to cron to suspend a job

POST /suspension-schedules

<suspensionSchedule>
  <workflow id="process-images"/>
 <time>some datetime afetr which to suspend</time>
</suspension>

.... nice candidate to re-use iCalender, BTW.

> - disable: change state of the resource to disabled

Which are all resource-state changes, too as you write yourself :-) Also, maybe these are not states but memberships in collection (e.g. move from draft to published queue/collection).

> These are actions i used frequently in various applications.

If it is an action, it is an implementation detail :-)

> Do you think it is reasonable to register all of these as link relations?
> 

Erm, no .... but you know that already ;-)

> Folks? What do you think?

YAGNI...

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Thu, 29 Aug 2013 01:04:23 +0400

Thank you Mike!

> "The link relation {value} identifies a target resource that represents {a concept}." There are variations, but you'll get the idea.

That is why i didn't start from particular actions and tried to create concept of "action". If i understand whole thing correctly "action" is a concept, though in this particular case it is too generic and has minimal value as far as it doesn't say anything about particular action and if representation includes several action links it is impossible to distinguish one from another.

Cheers,
ioseb

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Thu, 29 Aug 2013 01:54:28 +0400

Hi Jan,

Thanks for feedback! 

On Thursday, August 29, 2013 at 12:49 AM, Jan Algermissen wrote:

> 
> On 28.08.2013, at 21:38, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> 
> > 
> > As a conclusion:
> > 
Suppose i've application for managing services and i expose supported actions in following way(i use HTML for this example):

- <html> 
- ...
- <div class="actions">
- <form action="/suspend-action" method="post" class="suspend">
- <input type="hidden" name="suspend" value="true">
- <button type="submit">Suspend</button>
- </form>
- <form action="/restart-action" method="post" class="restart">
- <input type="hidden" name="restart" value="true">
- <button type="submit">Restart</button>
- </form>
- </div>
- ...
- </html>

Now lets say that i want to move these forms out of the service representation and make them separate resources. Now we need to advertise these resources to let agents know that a) such resources exist; and b) tell them why do they need to follow these links. One example could be:

- <html> 
- <head> 
- <link href="/suspend-action" rel="suspend-action">
- <link href="/suspend-action" rel="restart-action">
- </head>
- ...
- </html>

After activating one of the links:

- agent can fetch(HTTP GET) action description
- construct HTTP POST request based on action description(form in this case or whatever was used for describing action)
- send that request back to the server

If we define used link relations as:

- The link relation "restart-action" identifies a target resource that represents an *action* that can be used to restart running service or process.
- The link relation "suspend-action" identifies a target resource that represents an *action* that can be used to suspend running service or process.

Would it be RESTful or not? Where implementation details are leaked?

How in this case "restart" and "suspend" are different from for example "update" and "delete"? or how "suspend-action" and "restart-action" are different from for example "edit-form" and "create-form"? What is the difference?

Cheers,
ioseb

---

From: "Rushforth, Peter" <[email-masked]>
Date: Thu, 29 Aug 2013 14:37:01 +0000

Ioseb,

> Folks? What do you think? 

IMHO registering link relations in the absence of a media type is a bit fraught.  

If you have a specific media type in which the meanings of these link relations can be evaluated that might make it a bit easier to swallow.  The meaning of words can reasonably be different in different contexts, so reserving them at such a high level is not a good idea.

Regards,
Peter

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 30 Aug 2013 11:12:08 +0400

Hi Mark,

Thanks for response! 

On Thursday, August 29, 2013 at 7:36 AM, Mark Nottingham wrote:

> 
> On 28/08/2013, at 9:51 AM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> 
> > Now consider this link:
> > 
> Huh. Why not just use a link hint? E.g., 
> 
> Link: </suspend-action>; rel="suspend"; link-kind="action"; title="Suspend"
> 
> or somesuch?
I was trying to achieve different thing, but i'm now convinced that it approach is not good enough. At least i can try hints like you suggested. Thanks!

Cheers,
ioseb
 
> 
> See:
> http://tools.ietf.org/html/draft-nottingham-link-hint
> 
> 
> --
> Mark Nottingham http://www.mnot.net/

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Fri, 30 Aug 2013 11:14:52 +0400

Hi Peter,

> If you have a specific media type in which the meanings of these link relations can be evaluated that might make it a bit easier to swallow. The meaning of words can reasonably be different in diff…
I already mentioned this, but i never tried to register link rels i listed in my email, that is why i choose different approach and qualified these as "actions" not link rels. Thanks anyway!

Cheers,
ioseb

---

From: Erik Wilde <[email-masked]>
Date: Sat, 31 Aug 2013 09:40:39 -0700

hello.

> IOW, you do not need a 'delete' and an 'edit' entry, just a 'source' entry and then you go there to PUT or DELETE.

i agree, the link only tells you why you might want to follow it: 
because you want to engage in edit interactions with the source of the 
entry.

the allowed interactions are defined by the media type of the link 
target: if the link target is an AtomPub entry, then AtomPub tells you 
that you can attempt to PUT or DELETE and expect them to work as defined 
by AtomPub.

if a server serving such a link wanted to hint at the fact that a 
particular link target only supported PUT or DELETE (so that for example 
a UI could gray out the "delete" button), then it could use link hints 
to communicate this constraint in the link. this way, it would be 
possible for a client to avoid requests that are likely to fail.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: mike amundsen <[email-masked]>
Date: Sat, 31 Aug 2013 13:00:23 -0400

<tangent>
At this point, what we're discussing is affordance design.

I will confess that the desire to pack up all the information on how to
activate a transition into "hints" on a LINK element creates not just an
ugly affordance, but also one needlessly difficult to use/animate. This is
esp. true when machines are required to "so-somewhere-else" in order to
resolve the details of the affordance (e.g. using OPTIONS, packing all the
instructions in a document at the end of a rel-link, etc.).

why are we so unwilling to model FORMS? what is it about the FORM-style
affordance that is so unappealing to designers/developers?
</tangent>

mamund
+1.859.757.1449
skype: mca.amundsen

On Sat, Aug 31, 2013 at 12:40 PM, Erik Wilde <[email-masked]> wrote:

>>> "The link relation {value} identifies a target resource that represents
>>> {a concept}." There are variations, but you'll get the idea.
>>>
>> Yes. And do not let AtomPub's 'edit' fool you - it is just a bad choice.
>> 'Edit' should have been sth like 'source' because what edit identifies is
>> the one entry you need to direct requests to that intend to change the
>> entry - (as opposed to the member-entries that represent that 'edit'-entry
>> in individual collections.
>> IOW, you do not need a 'delete' and an 'edit' entry, just a 'source'
>> entry and then you go there to PUT or DELETE.
>>
>
> i agree, the link only tells you why you might want to follow it: because
> you want to engage in edit interactions with the source of the entry.
>
> the allowed interactions are defined by the media type of the link target:
> if the link target is an AtomPub entry, then AtomPub tells you that you can
> attempt to PUT or DELETE and expect them to work as defined by AtomPub.
>
> particular link target only supported PUT or DELETE (so that for example a
> UI could gray out the "delete" button), then it could use link hints to
> communicate this constraint in the link. this way, it would be possible for
> a client to avoid requests that are likely to fail.
>
> cheers,
>
> dret.
>
> --