<snip>

So here is my question: why is it bad?

</snip>

1) creates a new registry for action-type in= stead of using existing registry for rel (you point this out in the "t= here 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' ques= tion)

4) uses two values ("action" and "{reason}") whe= re only one is needed (srsly, a constant string AND a variable?)

IOW, you have two possib= le solutions already for the same outcome and are not using them. you'v= e been offered at least one issue on=A0conflicting=A0implementation and at = least one on overly-complex implementation.

if you are so sure that this implementation d= etail is important to the _results_ you want to achieve, then start today b= y doing it via link extensions:

you can document a= nd 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=A0to the way microformats operates). You can build = working implementations, write papers on it, advocate for use in various fo= rums, etc. =A0

Over time you can monitor and record adoption= , judge the=A0up-take y= ou 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:=A0<LINK rel=3D"http://actions.io/action;action-type=3D"sta= rt" ... />=A0wi= th=A0<LINK rel=3D&qu= ot;action;action-type=3D"start" ... />=A0and even allow existing implementations to s= upport both.

IOW, nothing is stoppin= g you from implementing a compliant version of this approach today and doin= g it in a way that would be compatible w/ adopting your proposed approach o= nce your approach is proven to be worthy of recording as a standard.=A0

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 h= ere.=A0

Cheers.

mamund

+1.859.757.144= 9
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/= mamund
http://www.linkedin.com/in/mikeamundsen

On Wed, Aug 28, 2013 at 12:41 PM, Ioseb = Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote= :

Mike,

On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote:
> Ioseb:
>

> now that i understand your aim...
>
> it seems the first item (support a pattern...) is the important one an= d 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 s= cenarios 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 t= hrow 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 serv= er.
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 consisten= t 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 n= o guarantee that each newly registered relation(which can be qualified as a= ction) 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=3D"actio= n start" />?

It was suggested in the initial proposal though approach has drawback= s. if i use more rels? <LINK rel=3D"action foo bar baz" /> = how to distinguish "foo", "bar" and "baz" fro= m 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 a= s in <LINK rel=3D"http://actions.io/start" ... />
>
> 4) why not use a unique element attribute/property such as <LINK re= l=3D"action" reason=3D"start" .../>?
>
>

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

> 5) why not use a unique document element/property such as <action r= el=3D"start" href=3D"..."/> 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

>
> mamund
> +1.859.757.14= 49
> skype: mca.amundsen
> http://amundse= n.com/blog/
> http://twitter= .com/mamund
> https://github= .com/mamund
> = http://www.linkedin.com/in/mikeamundsen
>

> On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanas= hvili <ioseb.dzmanashvil= i@gmail.com (mailto:ios= eb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote:
> > Mike,
> >
> > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > >
> > > OK, from your response i get the following:
> > >
> > > 1) you want to support a pattern where machine-readable stat= e 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 i= llustrations)
> > > 3) you want to indicate the reason for using these instructi= ons w/ an "action-type" string (via a link-rel param in your illu= strations)
> > >
> > > that's it. nothing else.
> > >
> > > do i have this correct?
> >
> > Exactly! That's it and nothing else.
> >
> > Cheers,
> > ioseb
> >
> > >
> > >
> > > mamund

> > > +1.859.757.1449 (tel:%2B1.859.757.1449)
> > > skype: mca.amundsen
> > > http= ://amundsen.com/blog/
> > > http= ://twitter.com/mamund
> > > http= s://github.com/mamund
> > > http://www.linkedin.com/in/mikeamundsen
> > >

> > > On Tue, Aug 27, 2013 at 7:51 PM= , Ioseb Dzmanashvili <io= seb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)= > wrote:
> > > > 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=3D"ac= tion;action-type=3D'edit'" href=3D"..." />
> > > > > is preferable to: <link rel=3D"edit" = href=3D"..." />
> > > > >
> > > > > talk me down ;)
> > > > let me try ;)
> > > >
> > > > Question is not about why: Link: <=85>; rel=3D&qu= ot;action"; action-type=3D"edit" is preferable to: Link: <= ;=85>; rel=3D"edit".
> > > >
> > > > Of course i'd choose rel=3D"run-forest-run&quo= t; if there is a registered link relation type, but:
> > > >
> > > > 1. The "action" link relation is generic enou= gh, has well understood meaning and is useful on its own especially for hum= an oriented agents.
> > > > 2. The "action-type" optional attribute may b= e 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=3D"action"= ; action-type=3D"suspend"; title=3D"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 de= tails etc
> > > > 3. agent can look inside "action-type" to det= ermine 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=3D"action"= ; action-type=3D"suspend"; title=3D"Suspend"
> > > > Link: </restart-action>; rel=3D"action"= ; action-type=3D"restart"; title=3D"Restart"
> > > >
> > > > Link: </stop-action>; rel=3D"action"; a= ction-type=3D"stop"; title=3D"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 nec= essary 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 an= swered)
> > > > 2. if user choose one agent needs just to dereference i= ndicated 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 &q= uot;action" relation type is useful and not because it is better(or si= mpler) compared to rel=3D"edit" for example.
> > > >
> > > > 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
> > > >
> > > > P.S.
> > > > I was talking about 01 version of spec. 00 is a differe= nt story.
> > > >
> > > > Cheers,
> > > > ioseb
> > > > > mamund

> > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.85= 9.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 <ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mai= lto:ioseb.dzmanashvili@gmai= l.com) (mailto:ioseb.dz= manashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote:
> > > > > > Hi Julian,
> > > > > >
> > > > > > Thanks for response!
> > > > > >
> > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julia= n Reschke wrote:
> > > > > >
> > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili = wrote:
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > I've updated the "action&q= uot; link relation type spec[1] based on initial feedback.
> > > > > > > >
> > > > > > > > As far as initial reactions were ve= ry controversial and raised a lot of issues i tried to address all of them = and entirely changed the spec.
> > > > > > > >
> > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > > When included in a response, the &q= uot;action" link relation indicates a
> > > > > > > > target resource that is responsible= for performing action which MAY:
> > > > > > > >
> > > > > > > > - Affect state of the context resou= rce; or
> > > > > > > > - Initiate process.
> > > > > > > >
> > > > > > > > The "action" link relatio= n type can be used to indicate the
> > > > > > > > availability of actions supported b= y the target resource. Examples
> > > > > > > > of such actions include:
> > > > > > > >
> > > > > > > > - Enable/Disable
> > > > > > > > - Publish/Unpublish
> > > > > > > > - Start/Stop
> > > > > > > >
> > > > > > > > The "action" link relatio= n type doesn't convey any semantics other
> > > > > > > > than that an indicated resources re= present machine readable
> > > > > > > > description of a particular action = and representation SHOULD contain
> > > > > > > > all necessary details such as: requ= est method, action URI and other
> > > > > > > > related details to enable agents to= be able to construct requests
> > > > > > > > without relying on out-of-band info= rmation.
> > > > > > > >
> > > > > > > > Exact type of action SHOULD be indi= cated through the "action-type"
> > > > > > > > link-extension value as per [RFC598= 8] and for maintaining shared
> > > > > > > > understanding of action types curre= nt specification introduces the
> > > > > > > > registry of actions with initial va= lues of widely accepted and well
> > > > > > > > understood action types.
> > > > > > > >
> > > > > > > > For example, if a resource represen= ts a service, that same
> > > > > > > > representation may include links to= resources that represent actions
> > > > > > > > supported by the service:
> > > > > > > >
> > > > > > > > Link: </restart-action>; rel= =3D"action"; action-type=3D"restart"
> > > > > > > > Link: </stop-action>; rel=3D&= quot;action"; action-type=3D"stop"
> > > > > > > > ...
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > It seems that you are just adding an ind= irection mechanism. Why is that
> > > > > > > necessary?
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > With indirection mechanism i'm trying to = solve issues raised around initial version of the spec[1]. There were sever= al 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 &= quot;action-type" link extension + registry of predefined action types= agents can distinguish actions from each other.
> > > > > >
> > > > > > 2. Initial spec stated that if the "acti= on" link exists in representation, only thing agents should do is to s= end empty POST request to the target in order to perform action. This appro= ach was considered as an anti pattern(RPCish and non RESTful). With having = the "action-type" agents can:
> > > > > >
> > > > > > a) distinguish action links from each other;<= br> > > > > > > b) if necessary dereference the target to obt= ain 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 s= tructure of the request according to there own needs.
> > > > > >
> > > > > > Main purpose of the "action" link r= elation 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 autom= ated agents not necessarily for human interaction oriented agents.
> > > > > >
> > > > > > Having action type registry is important for = maintaining shared understanding of particular action types. For example &q= uot;reset" or "publish" verbs do not need to be redefined fr= om application to application. I also believe that it is not efficient(or f= easible) to register all possible actions as link relations.
> > > > > >
> > > > > > 1. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00
> > > > > > 2. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01
> > > > > > >
> > > > > > > Best regards, Julian
> > > > > > Cheers,
> > > > > > ioseb
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > link-relations mailing list

> > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org)
> > > > > > https://www.ietf.org/mailman/listinfo= /link-relations
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

--047d7bae47381a1f2704e5057926-- From ioseb.dzmanashvili@gmail.com Wed Aug 28 12:38:11 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246EE11E81AF; Wed, 28 Aug 2013 12:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.347 X-Spam-Level: * X-Spam-Status: No, score=1.347 tagged_above=-999 required=5 tests=[AWL=-2.384, BAYES_50=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=0.6, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oFVMzh3JyP0; Wed, 28 Aug 2013 12:38:09 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id DA4D211E8178; Wed, 28 Aug 2013 12:38:08 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id l10so3174802eei.35 for ; Wed, 28 Aug 2013 12:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=T9DBwMree7sMDDKWoo7Q7JaZnMQVjJbVR6uQjyGKYFc=; b=sEn8mVonIsTxi/9XKD+pQsWZEf2/ZR35vtR04X9uWP4T1ZVmnvdEv03mHyrJJ4Rhon ziP7eKBAb6RClNlW8Elpr/mTM9JgIk/R6JUQx1Y2O48Q23KPSrxJz69znmbbEi0nXl1A ewuars9nIwEQQME2yN6+wkzHispHiqSPrO7NYubhX4HfNFlAMH+RZSi7bxDYzEgaBBq7 RyTr4sNrzm0GxDqfSneu4ykZSzlyN0B+22s7WIPbcLj/kTswpj6J7e6u6nUz4+6AE08D NMhpazAg+FXP7mAkE+Am8lsLVppc70Q/mI83pfFxCYpBWqHGV4iwzpnLlecgLE1cJjya 1x8Q== X-Received: by 10.14.241.74 with SMTP id f50mr45291462eer.29.1377718686934; Wed, 28 Aug 2013 12:38:06 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id j7sm40050776eeo.15.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:38:06 -0700 (PDT) Date: Wed, 28 Aug 2013 23:38:01 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

Subject: Re: [apps-discuss] NEW RELATION: 'action' version update X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 19:38:11 -0000 Mike, On Wednesday, August 28, 2013 at 9:39 PM, mike amundsen wrote: > > So here is my question: why is it bad=3F > > 1) creates a new registry for action-type instead of using existing reg= istry for rel (you point this out in the =22there is not start relation y= et=22 reasoning) > 2) ignores the use of link relation extension values already establishe= d in R=46C5988 (see Mike Kelly's question) > 3) introduces confusion on whether =40rel or =22action-type=22 should b= e used (see Peter Williams' question) > 4) uses two values (=22action=22 and =22=7Breason=7D=22) where only one= is needed (srsly, a constant string AND a variable=3F) =20 > =20 > IOW, you have two possible solutions already for the same outcome and a= re not using them. you've been offered at least one issue on conflicting = implementation and at least one on overly-complex implementation. =20 > =20 > if you are so sure that this implementation detail is important to the = =5Fresults=5F you want to achieve, then start today by doing it via link = extensions: =20 > > =20 > you can document and implement this today w/o any need to get an R=46C = 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, ad= vocate for use in various forums, etc. =20 > =20 I'd prefer to avoid this, i do not have enough resources to publicly main= tain such registry ;-) =20 > Over time you can monitor and record adoption, judge the up-take you ge= t and determine whether it proves to be a useful pattern. If it works wel= l and shows adoption, you'll see much less push-back from me (and, i susp= ect others) and will be able to replace: with and even allow existing implementations to su= pport both. =20 > =20 > IOW, nothing is stopping you from implementing a compliant version of t= his approach today and doing it in a way that would be compatible w/ adop= ting your proposed approach once your approach is proven to be worthy of = recording as a standard. =20 > =20 > finally, i'll say this: > > Actually as i see it =231 and =232 are of same importance. > > If the =5Fmethod=5F of achieving your results is non-negotiable, I have= little else to offer here > =20 All clear. As a conclusion: 1. Having the generic =22action=22 relation is worthless, at list as of 0= 0 and 01 proposals. At least i need to find better way to make it accepta= ble. 2. Action type registry complicates things(and i agree). 3. One possible way is to maintain separate registry(out of IET=46) which= is not feasible for me. 4. Most realistic is to register top level action link rels and i've seve= ral 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=3F =46olks=3F What do you think=3F Cheers, ioseb =20 > . =20 > =20 > Cheers. > =20 > =20 > 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 =20 > =20 > On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili wrote: > > Mike, > > =20 > > On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: > > > Ioseb: > > > =20 > > > now that i understand your aim... > > > =20 > > > 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 =231 and =232 are of same importance. > > =20 > > =20 > > > so why is this a good approach=3F > > =231 and =232 still hold. As i already said =233 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. > > =20 > > What i'm trying to achieve with my proposal is to generalise meaning = of action and make it consistent across different applications. Unfortuna= tely i do not see(or know, or was not able to find) better approach yet b= ut it is generic enough to solve whole class of problems at least on GUI = level + partially for m2m cases with =22action-type=22 attribute even if = we throw action type registry idea away. If we simplify definition of the= =22action=22 relation type and say: > > =20 > > 1. here is the =22action=22 link > > 2. it points to a resource which describes the action > > 3. to perform an action fetch it construct request and send it back t= o server. > > 4. if you want to know what this particular action means: > > 4.1. look inside the =22action-type=22 attribute if it presents; or > > 4.2. fetch the document and look inside it. > > =20 > > Is not it sufficient enough to cover whole class of problems in a con= sistent way which are clearly actions and not just related resources=3F > > =20 > > So here is my question: why is it bad=3F > > =20 > > > 1) why use the =22action=22 rel PLUS a param (=22start=22)=3F why n= ot just use the param (=22start=22) as the rel=3F > > =46or several reasons: > > =20 > > 1. there is no =22start=22 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 ther= e is no guarantee that each newly registered relation(which can be qualif= ied as action) will state that it is an action in a consistent way. > > 4. the pattern as you noticed is still important(IMHO) > > =20 > > > 2) why not use two values for the rel as in =3F > > =20 > > It was suggested in the initial proposal though approach has drawback= s. if i use more rels=3F how to d= istinguish =22foo=22, =22bar=22 and =22baz=22 from each other=3F does it = mean that my action now has triple meaning=3F > > =20 > > > 3) why not use (as mike kelly suggests) an extension URI for the re= l as in > > > =20 > > > 4) why not use a unique element attribute/property such as =3F > > =20 > > is it different from =22action-type=22 attribute=3F or maybe problem = is in a registry of action types=3F > > =20 > > > 5) why not use a unique document element/property such as or =7B=22action=22: =7B=22rel=22:=22s= tart=22, =22href=22:=22...=22=7D=7D=3F > > 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 u= se similar approach in practice. > > =20 > > Cheers, > > ioseb > > =20 > > > =20 > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > =20 > > > On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili wrote: > > > > Mike, > > > > =20 > > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > > > =20 > > > > > OK, from your response i get the following: > > > > > =20 > > > > > 1) you want to support a pattern where machine-readable state t= ransition instructions appear at the end of some URL. > > > > > 2) you want to indicate those instructions are available by mar= king the URL w/ the string literal =22action=22 (via rel in your illustra= tions) > > > > > 3) you want to indicate the reason for using these instructions= w/ an =22action-type=22 string (via a link-rel param in your illustratio= ns) > > > > > =20 > > > > > that's it. nothing else. > > > > > =20 > > > > > do i have this correct=3F > > > > =20 > > > > Exactly=21 That's it and nothing else. > > > > =20 > > > > Cheers, > > > > ioseb > > > > =20 > > > > > =20 > > > > > =20 > > > > > mamund > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449)= > > > > > skype: mca.amundsen > > > > > http://amundsen.com/blog/ > > > > > http://twitter.com/mamund > > > > > https://github.com/mamund > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > =20 > > > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili wrote: > > > > > > Hi Mike, > > > > > > =20 > > > > > > Thanks for the question=21 > > > > > > =20 > > > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:= > > > > > > =20 > > > > > > > Ioseb: > > > > > > > =20 > > > > > > > it is not clear to me why: > > > > > > > is preferable to: > > > > > > > =20 > > > > > > > talk me down ;) > > > > > > let me try ;) > > > > > > =20 > > > > > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action= =22; action-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D= =22edit=22. > > > > > > =20 > > > > > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a= registered link relation type, but: > > > > > > =20 > > > > > > 1. The =22action=22 link relation is generic enough, has well= understood meaning and is useful on its own especially for human oriente= d agents. > > > > > > 2. The =22action-type=22 optional attribute may be used for s= pecifying exact meaning of actions and this makes action links more usefu= l for m2m scenarios. > > > > > > =20 > > > > > > Now consider this link: > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= suspend=22; title=3D=22Suspend=22 > > > > > > =20 > > > > > > What it says=3F > > > > > > =20 > > > > > > 1. it is an action > > > > > > 2. target resource represents description of the action which= contains: request method, submit URI, definition of action, other detail= s etc > > > > > > 3. agent can look inside =22action-type=22 to determine wheth= er it needs this action type or not > > > > > > 4. agent can dereference it, construct request and send it to= server > > > > > > =20 > > > > > > =20 > > > > > > now if we add more actions: > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= suspend=22; title=3D=22Suspend=22 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= restart=22; title=3D=22Restart=22 > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22st= op=22; title=3D=22Stop=22 > > > > > > =20 > > > > > > =20 > > > > > > =231, =232, =233 and =234 will be true for all of them withou= t exceptions. > > > > > > =20 > > > > > > Now consider that representation containing these links is us= ed by GUI agent, in this case even =22action-type=22 is not necessary at = all and agent can rely on user's choice. Agent only needs to know that: > > > > > > =20 > > > > > > 1. link is an action(and this question is explicitly answered= ) > > > > > > 2. if user choose one agent needs just to dereference indicat= ed URI > > > > > > 3. construct request > > > > > > 4. send request to server > > > > > > 5. show results to user > > > > > > =20 > > > > > > All of these will remain true for any action type. > > > > > > =20 > > > > > > I'm not sure if i talked you down, but i believe =22action=22= relation type is useful and not because it is better(or simpler) compare= d to rel=3D=22edit=22 for example. > > > > > > =20 > > > > > > 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 > > > > > > =20 > > > > > > P.S. > > > > > > I was talking about 01 version of spec. 00 is a different sto= ry. > > > > > > =20 > > > > > > Cheers, > > > > > > ioseb > > > > > > > mamund > > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1= 449) (tel:%2B1.859.757.1449) > > > > > > > skype: mca.amundsen > > > > > > > http://amundsen.com/blog/ > > > > > > > http://twitter.com/mamund > > > > > > > https://github.com/mamund > > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili wrote: > > > > > > > > Hi Julian, > > > > > > > > =20 > > > > > > > > Thanks for response=21 > > > > > > > > =20 > > > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wr= ote: > > > > > > > > =20 > > > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > > > > Hi All, > > > > > > > > > > =20 > > > > > > > > > > I've updated the =22action=22 link relation type spec= =5B1=5D based on initial feedback. > > > > > > > > > > =20 > > > > > > > > > > As far as initial reactions were very controversial a= nd raised a lot of issues i tried to address all of them and entirely cha= nged the spec. > > > > > > > > > > =20 > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > When included in a response, the =22action=22 link re= lation indicates a > > > > > > > > > > target resource that is responsible for performing ac= tion which MAY: > > > > > > > > > > =20 > > > > > > > > > > - Affect state of the context resource; or > > > > > > > > > > - Initiate process. > > > > > > > > > > =20 > > > > > > > > > > The =22action=22 link relation type can be used to in= dicate the > > > > > > > > > > availability of actions supported by the target resou= rce. Examples > > > > > > > > > > of such actions include: > > > > > > > > > > =20 > > > > > > > > > > - Enable/Disable > > > > > > > > > > - Publish/Unpublish > > > > > > > > > > - Start/Stop > > > > > > > > > > =20 > > > > > > > > > > The =22action=22 link relation type doesn't convey an= y semantics other > > > > > > > > > > than that an indicated resources represent machine re= adable > > > > > > > > > > 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 constr= uct requests > > > > > > > > > > without relying on out-of-band information. > > > > > > > > > > =20 > > > > > > > > > > Exact type of action SHOULD be indicated through the = =22action-type=22 > > > > > > > > > > link-extension value as per =5BR=46C5988=5D and for m= aintaining shared > > > > > > > > > > understanding of action types current specification i= ntroduces the > > > > > > > > > > registry of actions with initial values of widely acc= epted and well > > > > > > > > > > understood action types. > > > > > > > > > > =20 > > > > > > > > > > =46or example, if a resource represents a service, th= at same > > > > > > > > > > representation may include links to resources that re= present actions > > > > > > > > > > supported by the service: > > > > > > > > > > =20 > > > > > > > > > > Link: ; rel=3D=22action=22; action-t= ype=3D=22restart=22 > > > > > > > > > > Link: ; rel=3D=22action=22; action-type= =3D=22stop=22 > > > > > > > > > > ... > > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > It seems that you are just adding an indirection mechan= ism. Why is that > > > > > > > > > necessary=3F > > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > With indirection mechanism i'm trying to solve issues rai= sed around initial version of the spec=5B1=5D. There were several issues:= > > > > > > > > =20 > > > > > > > > 1. The =22action=22 link relation type doesn't have enoug= h semantics and automated agents can not follow such links if there are s= everal actions included in a representation. With the =22action-type=22 l= ink extension + registry of predefined action types agents can distinguis= h actions from each other. > > > > > > > > =20 > > > > > > > > 2. Initial spec stated that if the =22action=22 link exis= ts in representation, only thing agents should do is to send empty POST r= equest to the target in order to perform action. This approach was consid= ered as an anti pattern(RPCish and non RESTful). With having the =22actio= n-type=22 agents can: > > > > > > > > =20 > > > > > > > > a) distinguish action links from each other; > > > > > > > > b) if necessary dereference the target to obtain instruct= ions 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. > > > > > > > > =20 > > > > > > > > Main purpose of the =22action=22 link relation type is to= define semantics of particular class of links - actions. This eliminates= the need to redefine notion of =22action=22 for each link relation type = which may be qualified as action link. The =22action-type=22 is just for = naming actions and is particularly useful for automated agents not necess= arily for human interaction oriented agents. > > > > > > > > =20 > > > > > > > > Having action type registry is important for maintaining = shared understanding of particular action types. =46or example =22reset=22= or =22publish=22 verbs do not need to be redefined from application to a= pplication. I also believe that it is not efficient(or feasible) to regis= ter all possible actions as link relations. > > > > > > > > =20 > > > > > > > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-ac= tion-link-relation-00 > > > > > > > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-ac= tion-link-relation-01 > > > > > > > > > =20 > > > > > > > > > Best regards, Julian > > > > > > > > Cheers, > > > > > > > > ioseb > > > > > > > > =20 > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F > > > > > > > > link-relations mailing list > > > > > > > > link-relations=40ietf.org (mailto:link-relations=40ietf.o= rg) (mailto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org)= (mailto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org) (m= ailto:link-relations=40ietf.org) > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > =20 > > > > > > =20 > > > > > =20 > > > > > =20 > > > > =20 > > > > =20 > > > =20 > > > =20 > > =20 > > =20 > =20 > =20 From mca@amundsen.com Wed Aug 28 13:02:48 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC26921F9D53 for ; Wed, 28 Aug 2013 13:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.28 X-Spam-Level: **** X-Spam-Status: No, score=4.28 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae725-nc6eSN for ; Wed, 28 Aug 2013 13:02:45 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 95BAE11E8175 for ; Wed, 28 Aug 2013 13:02:44 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u54so5507487wes.23 for ; Wed, 28 Aug 2013 13:02:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=Co0gVadWXsrHgP3exQ3gXN0cwr3wjU72GEVBmVRIsbs=; b=bIcjBMXJryHruN+5Q/3U4Q/nRSGK7106SrLjIxLO+1/a8aBFjOSnWuB7nijFN3nj37 i4JItfYsbZC0jglm4eFqxoI9/oD2ZfjKz+Ha/hkzYPgJWXQy2Ygqb8f//2Xp++dYaS3U pQVmRdLxj9UyH7OyXm8C0gi42VsFyh0LVUjq6b/5mv55Cq4l7+EyXjeSCOLtklDhuooO v1I08H61ka1nDQQ/xCweYcC1RHoXfmiDmFhIUJ1lfhTXjrrjYZfS1MMHKZFRF+A6DwEY GlTPr5UQL+H46jlrciByMzf0me9cayC3Tg5zAddOWJcQotEj8kH7glDs4yEMGggljnXN b05w== X-Gm-Message-State: ALoCoQmIxguQ3J7tViL7HRgGdTpSOqJa+hc2RJQkBDQmArZb0iAr1ezfiopn6wZhg72IC17GHFpA X-Received: by 10.194.93.135 with SMTP id cu7mr5101136wjb.73.1377720159661; Wed, 28 Aug 2013 13:02:39 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Wed, 28 Aug 2013 13:02:19 -0700 (PDT) In-Reply-To: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

<30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> From: mike amundsen Date: Wed, 28 Aug 2013 16:02:19 -0400 X-Google-Sender-Auth: fYDpH5XD66dpILJzv8ltAX4BVOM Message-ID: Subject: Re: [apps-discuss] NEW RELATION: 'action' version update To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bb03eb6b782fe04e50778ce Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:02:49 -0000 --047d7bb03eb6b782fe04e50778ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Wed, Aug 28, 2013 at 3:38 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > On Wednesday, August 28, 2013 at 9:39 PM, mike amundsen wrote: > > > > > So here is my question: why is it bad? > > > > 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 establishe= d > 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 ge= t > 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 suspec= t > others) and will be able to replace: http://actions.io/action;action-type=3D"start" ... /> with rel=3D"action;action-type=3D"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: > > > > Actually as i see it #1 and #2 are of same importance. > > > > 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 an= d > 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 i= s > 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 > > > . > > > > Cheers. > > > > > > 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 Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com)> wrote= : > > > Mike, > > > > > > On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: > > > > 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. > > > 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 h= ow > 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 definitio= n > 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 t= o > 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 us= e > 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 ther= e > is no guarantee that each newly registered relation(which can be qualifie= d > 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 />? > > > > > > It was suggested in the initial proposal though approach has > drawbacks. if i use more rels? 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 re= l > as in > > > > > > > > 4) why not use a unique element attribute/property such as rel=3D"action" reason=3D"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 rel=3D"start" href=3D"..."/> 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 us= e > similar approach in practice. > > > > > > Cheers, > > > ioseb > > > > > > > > > > > mamund > > > > +1.859.757.1449 (tel:%2B1.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 Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m)> > wrote: > > > > > Mike, > > > > > > > > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > > > > > > > > > > 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? > > > > > > > > > > Exactly! That's it and nothing else. > > > > > > > > > > Cheers, > > > > > ioseb > > > > > > > > > > > > > > > > > > > > > > > mamund > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.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 7:51 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com)> wrote: > > > > > > > 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: rel=3D"action;action-type=3D'edit'" href=3D"..." /> > > > > > > > > is preferable to: > > > > > > > > > > > > > > > > talk me down ;) > > > > > > > let me try ;) > > > > > > > > > > > > > > Question is not about why: Link: <=85>; rel=3D"action"; > action-type=3D"edit" is preferable to: Link: <=85>; rel=3D"edit". > > > > > > > > > > > > > > Of course i'd choose rel=3D"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 usef= ul > for m2m scenarios. > > > > > > > > > > > > > > Now consider this link: > > > > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"suspe= nd"; > title=3D"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 i= t > 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: ; rel=3D"action"; action-type=3D"suspe= nd"; > title=3D"Suspend" > > > > > > > Link: ; rel=3D"action"; action-type=3D"resta= rt"; > title=3D"Restart" > > > > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"stop"; > title=3D"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 al= l > 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=3D"edit" for example. > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > P.S. > > > > > > > I was talking about 01 version of spec. 00 is a different > story. > > > > > > > > > > > > > > Cheers, > > > > > > > ioseb > > > > > > > > mamund > > > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > (tel:%2B1.859.757.1449) (tel:%2B1.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 < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com)> wrote: > > > > > > > > > Hi Julian, > > > > > > > > > > > > > > > > > > Thanks for response! > > > > > > > > > > > > > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke > wrote: > > > > > > > > > > > > > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > 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: ; rel=3D"action"; > action-type=3D"restart" > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"= stop" > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that you are just adding an indirection > mechanism. Why is that > > > > > > > > > > necessary? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 i= n > 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 f= or > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > link-relations mailing list > > > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto= : > link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto: > link-relations@ietf.org) > > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --047d7bb03eb6b782fe04e50778ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

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

1) check out the micr= oformats existing rel values page[1] along with the usual IANA Link Relatio= ns page[2]. And the Dublin Core page has some good stuff, too[3]. these wil= l give you an idea of what's already out there and some sense of what i= s in use. Peeking at Schema.org[4] and Activity Streams[5] may help, but i&= #39;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} identifi= es a target resource that represents {a concept}." There are variation= s, but you'll get the idea.

3) once you have solid defs/values and documentation, i'd post t= hat 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 als= o very quick to provide feedback. i've had a good experience there.

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

Of course, you can start using the values now (and getting othe= rs to do the same) by relying on the Link Extension rules from 5988[6]. Wat= ching that unfold will give you and idea on the usefulness/popularity of yo= ur 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]=A0http://microformats.org/wiki/existing-rel-val= ues

[2]=A0http://www.iana.org/assignment= s/link-relations/link-relations.xml

[3]=A0http://dublincore.org/documents/dc-html/

[4]=A0http://schema.org/

[5]=A0http://activitystrea.ms/

[6]=A0http:= //tools.ietf.org/html/rfc5988#section-4.2

[7]=A0http://amundsen.com/media-typ= es/linkrelations/

mamu= nd

+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 Wed, Aug 28, 2013 at 3:38 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=

Mike,

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

> <snip>
> So here is my question: why is it bad?
> </snip>
> 1) creates a new registry for action-type instead of using existing re= gistry 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 establish= ed in RFC5988 (see Mike Kelly's question)
> 3) introduces confusion on whether @rel or "action-type" sho= uld 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 conflicti= ng 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 exten= sions:
> <LINK rel=3D"http://actions.io/action;action-type=3D"sta= rt" ... />
>
> you can document and implement this today w/o any need to get an RFC a= pproved or get even buy-in from others. You can create your own registry an= d open it up to others for adds/edits (similar to the way microformats oper= ates). 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 publi= cly maintain such registry ;-)

> Over time you can monitor and record adoption, judge the up-take you g= et 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 sus= pect others) and will be able to replace: <LINK rel=3D"http://actions.io= /action;action-type=3D"start" ... /> with <LINK rel=3D&= quot;action;action-type=3D"start" ... /> and even allow existi= ng 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/ adopt= ing your proposed approach once your approach is proven to be worthy of rec= ording 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 li= ttle 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 accep= table.
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 se= veral 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 i= t is reasonable to register all of these as link relations?

Folks? What do you think?

Cheers,
ioseb

> .

>
> Cheers.
>
>
> mamund
> +1.859.757.14= 49
> skype: mca.amundsen
> http://amundse= n.com/blog/
> http://twitter= .com/mamund
> https://github= .com/mamund
> = http://www.linkedin.com/in/mikeamundsen
>

> On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmana= shvili <ioseb.dzmanashvi= li@gmail.com (mailto:io= seb.dzmanashvili@gmail.com)> wrote:
> > Mike,
> >

> > On Wednesday, August 28, 2013 at 6:3= 3 PM, mike amundsen wrote:
> > > Ioseb:
> > >
> > > now that i understand your aim...
> > >
> > > it seems the first item (support a pattern...) is the import= ant 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 m= 2m 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. Unf= ortunately i do not see(or know, or was not able to find) better approach y= et but it is generic enough to solve whole class of problems at least on GU= I level + partially for m2m cases with "action-type" attribute ev= en 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 ba= ck to server.
> > 4. if you want to know what this particular action means:
> > 4.1. look inside the "action-type" attribute if it pres= ents; 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 ("st= art")? 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 qual= ified 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=3D&= quot;action start" />?
> >
> > It was suggested in the initial proposal though approach has draw= backs. if i use more rels? <LINK rel=3D"action foo bar baz" /&= gt; 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=3D"http://actions.io/start" ... />
> > >
> > > 4) why not use a unique element attribute/property such as &= lt;LINK rel=3D"action" reason=3D"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 &l= t;action rel=3D"start" href=3D"..."/> or {"acti= on": {"rel":"start", "href":"...&qu= ot;}}?
> > Well, in custom media types i can do anything, though it doesn= 9;t make sense outside of particular format or domain. Otherwise it is ok a= nd i use similar approach in practice.
> >
> > Cheers,
> > ioseb
> >
> > >
> > > mamund

> > > +1.859.757.1449 (tel:%2B1.859.757.1449)
> > > skype: mca.amundsen
> > > http= ://amundsen.com/blog/
> > > http= ://twitter.com/mamund
> > > http= s://github.com/mamund
> > > http://www.linkedin.com/in/mikeamundsen
> > >

> > > On Wed, Aug 28, 2013 at 3:35 AM, Ios= eb Dzmanashvili <ioseb.d= zmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> = wrote:
> > > > Mike,
> > > >
> > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen= wrote:
> > > >
> > > > > OK, from your response i get the following:
> > > > >
> > > > > 1) you want to support a pattern where machine-rea= dable state transition instructions appear at the end of some URL.
> > > > > 2) you want to indicate those instructions are ava= ilable 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
> > > >
> > > > >
> > > > >
> > > > > mamund

> > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.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 7:51 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mai= lto:ioseb.dzmanashvili@gmai= l.com) (mailto:ioseb.dz= manashvili@gmail.com)> wrote:
> > > > > > 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= =3D"action;action-type=3D'edit'" href=3D"..." /= >
> > > > > > > is preferable to: <link rel=3D"e= dit" href=3D"..." />
> > > > > > >
> > > > > > > talk me down ;)
> > > > > > let me try ;)
> > > > > >
> > > > > > Question is not about why: Link: <=85>;= rel=3D"action"; action-type=3D"edit" is preferable to:= Link: <=85>; rel=3D"edit".
> > > > > >
> > > > > > Of course i'd choose rel=3D"run-fore= st-run" if there is a registered link relation type, but:
> > > > > >
> > > > > > 1. The "action" link relation is ge= neric enough, has well understood meaning and is useful on its own especial= ly for human oriented agents.
> > > > > > 2. The "action-type" optional attri= bute may be used for specifying exact meaning of actions and this makes act= ion links more useful for m2m scenarios.
> > > > > >
> > > > > > Now consider this link:
> > > > > >
> > > > > > Link: </suspend-action>; rel=3D"ac= tion"; action-type=3D"suspend"; title=3D"Suspend"<= br> > > > > > >
> > > > > > 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&qu= ot; to determine whether it needs this action type or not
> > > > > > 4. agent can dereference it, construct reques= t and send it to server
> > > > > >
> > > > > >
> > > > > > now if we add more actions:
> > > > > >
> > > > > > Link: </suspend-action>; rel=3D"ac= tion"; action-type=3D"suspend"; title=3D"Suspend"<= br> > > > > > > Link: </restart-action>; rel=3D"ac= tion"; action-type=3D"restart"; title=3D"Restart"<= br> > > > > > >
> > > > > > Link: </stop-action>; rel=3D"actio= n"; action-type=3D"stop"; title=3D"Stop"
> > > > > >
> > > > > >
> > > > > > #1, #2, #3 and #4 will be true for all of the= m without exceptions.
> > > > > >
> > > > > > Now consider that representation containing t= hese 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 exp= licitly answered)
> > > > > > 2. if user choose one agent needs just to der= eference 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 be= tter(or simpler) compared to rel=3D"edit" for example.
> > > > > >
> > > > > > 1. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00
> > > > > > 2. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01
> > > > > >
> > > > > > P.S.
> > > > > > I was talking about 01 version of spec. 00 is= a different story.
> > > > > >
> > > > > > Cheers,
> > > > > > ioseb
> > > > > > > mamund

> > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (t= el:%2B1.859.757.1449) (tel:%2B1.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 <ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:<= a href=3D"mailto:ioseb.dzmanashvili@gmail.com">ioseb.dzmanashvili@gmail.com= ) (mailto:ioseb.dzmanas= hvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote= :
> > > > > > > > Hi Julian,
> > > > > > > >
> > > > > > > > Thanks for response!
> > > > > > > >
> > > > > > > > On Tuesday, August 27, 2013 at 2:15= PM, Julian Reschke wrote:
> > > > > > > >
> > > > > > > > > On 2013-08-27 11:03, Ioseb Dzm= anashvili wrote:
> > > > > > > > > > Hi All,
> > > > > > > > > >
> > > > > > > > > > I've updated the &quo= t;action" link relation type spec[1] based on initial feedback.
> > > > > > > > > >
> > > > > > > > > > As far as initial reactio= ns were very controversial and raised a lot of issues i tried to address al= l of them and entirely changed the spec.
> > > > > > > > > >
> > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > > > > When included in a respon= se, the "action" link relation indicates a
> > > > > > > > > > target resource that is r= esponsible for performing action which MAY:
> > > > > > > > > >
> > > > > > > > > > - Affect state of the con= text resource; or
> > > > > > > > > > - Initiate process.
> > > > > > > > > >
> > > > > > > > > > The "action" li= nk relation type can be used to indicate the
> > > > > > > > > > availability of actions s= upported by the target resource. Examples
> > > > > > > > > > of such actions include:<= br> > > > > > > > > > >
> > > > > > > > > > - Enable/Disable
> > > > > > > > > > - Publish/Unpublish
> > > > > > > > > > - Start/Stop
> > > > > > > > > >
> > > > > > > > > > The "action" li= nk relation type doesn't convey any semantics other
> > > > > > > > > > than that an indicated re= sources represent machine readable
> > > > > > > > > > description of a particul= ar action and representation SHOULD contain
> > > > > > > > > > all necessary details suc= h 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 SHOU= LD be indicated through the "action-type"
> > > > > > > > > > link-extension value as p= er [RFC5988] and for maintaining shared
> > > > > > > > > > understanding of action t= ypes current specification introduces the
> > > > > > > > > > registry of actions with = initial values of widely accepted and well
> > > > > > > > > > understood action types.<= br> > > > > > > > > > >
> > > > > > > > > > For example, if a resourc= e represents a service, that same
> > > > > > > > > > representation may includ= e links to resources that represent actions
> > > > > > > > > > supported by the service:=
> > > > > > > > > >
> > > > > > > > > > Link: </restart-action= >; rel=3D"action"; action-type=3D"restart"
> > > > > > > > > > Link: </stop-action>= ;; rel=3D"action"; action-type=3D"stop"
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > It seems that you are just add= ing an indirection mechanism. Why is that
> > > > > > > > > necessary?
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 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 rela= tion type doesn't have enough semantics and automated agents can not fo= llow such links if there are several actions included in a representation. = With the "action-type" link extension + registry of predefined ac= tion 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). Wi= th having the "action-type" agents can:
> > > > > > > >
> > > > > > > > a) distinguish action links from ea= ch other;
> > > > > > > > b) if necessary dereference the tar= get to obtain instructions for constructing non empty POST/PUT requests; > > > > > > > > c) send properly constructed reques= t 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&qu= ot; 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 &q= uot;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 impo= rtant for maintaining shared understanding of particular action types. For = example "reset" or "publish" verbs do not need to be re= defined from application to application. I also believe that it is not effi= cient(or feasible) to register all possible actions as link relations.
> > > > > > > >
> > > > > > > > 1. h= ttp://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00<= /a>
> > > > > > > > 2. h= ttp://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01<= /a>
> > > > > > > > >
> > > > > > > > > Best regards, Julian
> > > > > > > > Cheers,
> > > > > > > > ioseb
> > > > > > > >
> > > > > > > > ___________________________________= ____________
> > > > > > > > link-relations mailing list

> > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mail= to:link-relations@ietf.org) = (mailto:link-relations@ietf.org<= /a>)
> > > > > > > > https://www.ietf.org/mailma= n/listinfo/link-relations
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

--047d7bb03eb6b782fe04e50778ce-- From jan.algermissen@nordsc.com Wed Aug 28 13:27:33 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA4511E819B; Wed, 28 Aug 2013 13:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IkFKlI5YQAq; Wed, 28 Aug 2013 13:27:28 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61B11E8159; Wed, 28 Aug 2013 13:27:27 -0700 (PDT) Received: from [192.168.2.107] (p548FAC9C.dip0.t-ipconnect.de [84.143.172.156]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MW4Sq-1VYW8Y3uFE-00X6NA; Wed, 28 Aug 2013 22:27:23 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [apps-discuss] NEW RELATION: 'action' version update From: Jan Algermissen In-Reply-To: Date: Wed, 28 Aug 2013 22:27:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

<30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> To: mike amundsen X-Mailer: Apple Mail (2.1508) X-Provags-ID: V02:K0:r/68N8fT8kTJjVskNq3WucdMpKE3fuFCLij+Lbb5AqN ypjFwy7M/JPGhl4favwCK4dR09OFEfolsQV4PxrPWX8OkfG/tk ErZ4Fw0QI47SfV3zbta9ij6s1RHvczRXh4BZVjNCJVVEjOH9Vy 60W5URk/MLyPJj5HUVJ4SA0zyXYmKBPbZ+D/iTh3VF69NXVM9m BUJqsF+q5Ib6FSrKMtn3YNW2CRICE+Cd/doyhaljzldXPBimRf wtn868Bef9UoBGRxFQdpt9ZW2bOjn9RLU3ySFuNJV8uEdTJmI8 OcIC2nVgXO5kgh1Ot4V6aNzlbAJk14KH3XarthlSAhS+WjuvaJ yRG0mEDN/j6exAY7uIGv1oqSV5CBOP0hA4O/cQWxYPqn/pjJdU 84/qI7gWRO0HQ== Cc: Julian Reschke , link-relations , IETF Apps Discuss X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:27:33 -0000 On 28.08.2013, at 22:02, mike amundsen 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@nordsc.com Wed Aug 28 13:49:45 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F1121F91BF; Wed, 28 Aug 2013 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.595 X-Spam-Level: * X-Spam-Status: No, score=1.595 tagged_above=-999 required=5 tests=[AWL=-2.356, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQbFk40XyT0l; Wed, 28 Aug 2013 13:49:41 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id D5EF821F8FF5; Wed, 28 Aug 2013 13:49:40 -0700 (PDT) Received: from [192.168.2.107] (p548FAC9C.dip0.t-ipconnect.de [84.143.172.156]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MfIF8-1VPBis2POs-00Oot3; Wed, 28 Aug 2013 22:49:12 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [apps-discuss] NEW RELATION: 'action' version update From: Jan Algermissen In-Reply-To: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> Date: Wed, 28 Aug 2013 22:49:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

<30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1508) X-Provags-ID: V02:K0:LK6tnblBS3p32RXIiWmrDXi5u13bK34mUKwJt4npbG+ 7unHaPN6ZeahlqD9wS7zWWq7Hr3gBc5ghS1amx4GUXyGdDoZM3 bkBzVVUmhD7yH7fTP8ZVbXzIoTiJ40BFeGc0sEVp31MnLyRbd6 qIK89kQt/00jmqws5Lh/WlXrnNmTWopMGKbf9YTh+/JNqgJ0gs Obi2dLPCUYphdIhp0+oKulgCloYpEgW/pv6EwCxo/H0D7RhIXp 0DgmjF48un+vvUQo5cmmRSQbYCiLsJRaxTtlK/QG/EREojG/RS JbwYYPXvYmFw03V/PVf0U/AnyUK60cRgV4bpJ3y0W+gR77QH3W b5vBP4GDTdhu7WlYLttq6TZstZfYHRtJN5D5DrH8w0yGL81YGo 0VgbAzWbLo0yA== Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:49:45 -0000 On 28.08.2013, at 21:38, Ioseb Dzmanashvili = wrote: >=20 > As a conclusion: >=20 > 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 ? > 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: >=20 > - 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 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 - 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 some datetime afetr which to suspend .... nice candidate to re-use iCalender, BTW. >=20 > - 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 >=20 > - enable: change state of the resource to enabled > - disable: change state of the resource to disabled >=20 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? >=20 Erm, no .... but you know that already ;-) > Folks? What do you think? >=20 YAGNI... Jan > Cheers, > ioseb >=20 >> . =20 >>=20 >> Cheers. >>=20 >>=20 >> 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 =20 >>=20 >> On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili = = wrote: >>> Mike, >>>=20 >>> On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: >>>> Ioseb: >>>>=20 >>>> now that i understand your aim... >>>>=20 >>>> 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. >>>=20 >>>=20 >>>> 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. >>>=20 >>> 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: >>>=20 >>> 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. >>>=20 >>> Is not it sufficient enough to cover whole class of problems in a = consistent way which are clearly actions and not just related resources? >>>=20 >>> So here is my question: why is it bad? >>>=20 >>>> 1) why use the "action" rel PLUS a param ("start")? why not just = use the param ("start") as the rel? >>> For several reasons: >>>=20 >>> 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) >>>=20 >>>> 2) why not use two values for the rel as in ? >>>=20 >>> It was suggested in the initial proposal though approach has = drawbacks. if i use more rels? how = to distinguish "foo", "bar" and "baz" from each other? does it mean that = my action now has triple meaning? >>>=20 >>>> 3) why not use (as mike kelly suggests) an extension URI for the = rel as in >>>>=20 >>>> 4) why not use a unique element attribute/property such as ? >>>=20 >>> is it different from "action-type" attribute? or maybe problem is in = a registry of action types? >>>=20 >>>> 5) why not use a unique document element/property such as 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. >>>=20 >>> Cheers, >>> ioseb >>>=20 >>>>=20 >>>> mamund >>>> +1.859.757.1449 (tel:%2B1.859.757.1449) >>>> skype: mca.amundsen >>>> http://amundsen.com/blog/ >>>> http://twitter.com/mamund >>>> https://github.com/mamund >>>> http://www.linkedin.com/in/mikeamundsen >>>>=20 >>>> On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili = wrote: >>>>> Mike, >>>>>=20 >>>>> On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: >>>>>=20 >>>>>> OK, from your response i get the following: >>>>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> that's it. nothing else. >>>>>>=20 >>>>>> do i have this correct? >>>>>=20 >>>>> Exactly! That's it and nothing else. >>>>>=20 >>>>> Cheers, >>>>> ioseb >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> mamund >>>>>> +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) >>>>>> skype: mca.amundsen >>>>>> http://amundsen.com/blog/ >>>>>> http://twitter.com/mamund >>>>>> https://github.com/mamund >>>>>> http://www.linkedin.com/in/mikeamundsen >>>>>>=20 >>>>>> On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili = wrote: >>>>>>> Hi Mike, >>>>>>>=20 >>>>>>> Thanks for the question! >>>>>>>=20 >>>>>>> On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: >>>>>>>=20 >>>>>>>> Ioseb: >>>>>>>>=20 >>>>>>>> it is not clear to me why: >>>>>>>> is preferable to: >>>>>>>>=20 >>>>>>>> talk me down ;) >>>>>>> let me try ;) >>>>>>>=20 >>>>>>> Question is not about why: Link: <=85>; rel=3D"action"; = action-type=3D"edit" is preferable to: Link: <=85>; rel=3D"edit". >>>>>>>=20 >>>>>>> Of course i'd choose rel=3D"run-forest-run" if there is a = registered link relation type, but: >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Now consider this link: >>>>>>>=20 >>>>>>> Link: ; rel=3D"action"; action-type=3D"suspend"; = title=3D"Suspend" >>>>>>>=20 >>>>>>> What it says? >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>>=20 >>>>>>> now if we add more actions: >>>>>>>=20 >>>>>>> Link: ; rel=3D"action"; action-type=3D"suspend"; = title=3D"Suspend" >>>>>>> Link: ; rel=3D"action"; action-type=3D"restart"; = title=3D"Restart" >>>>>>>=20 >>>>>>> Link: ; rel=3D"action"; action-type=3D"stop"; = title=3D"Stop" >>>>>>>=20 >>>>>>>=20 >>>>>>> #1, #2, #3 and #4 will be true for all of them without = exceptions. >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> All of these will remain true for any action type. >>>>>>>=20 >>>>>>> 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=3D"edit" for example. >>>>>>>=20 >>>>>>> 1. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 0 >>>>>>> 2. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 1 >>>>>>>=20 >>>>>>> P.S. >>>>>>> I was talking about 01 version of spec. 00 is a different story. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> ioseb >>>>>>>> mamund >>>>>>>> +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) = (tel:%2B1.859.757.1449) >>>>>>>> skype: mca.amundsen >>>>>>>> http://amundsen.com/blog/ >>>>>>>> http://twitter.com/mamund >>>>>>>> https://github.com/mamund >>>>>>>> http://www.linkedin.com/in/mikeamundsen >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili = wrote: >>>>>>>>> Hi Julian, >>>>>>>>>=20 >>>>>>>>> Thanks for response! >>>>>>>>>=20 >>>>>>>>> On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: >>>>>>>>>=20 >>>>>>>>>> On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>>=20 >>>>>>>>>>> I've updated the "action" link relation type spec[1] based = on initial feedback. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>>>>>>>> When included in a response, the "action" link relation = indicates a >>>>>>>>>>> target resource that is responsible for performing action = which MAY: >>>>>>>>>>>=20 >>>>>>>>>>> - Affect state of the context resource; or >>>>>>>>>>> - Initiate process. >>>>>>>>>>>=20 >>>>>>>>>>> The "action" link relation type can be used to indicate the >>>>>>>>>>> availability of actions supported by the target resource. = Examples >>>>>>>>>>> of such actions include: >>>>>>>>>>>=20 >>>>>>>>>>> - Enable/Disable >>>>>>>>>>> - Publish/Unpublish >>>>>>>>>>> - Start/Stop >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> For example, if a resource represents a service, that same >>>>>>>>>>> representation may include links to resources that represent = actions >>>>>>>>>>> supported by the service: >>>>>>>>>>>=20 >>>>>>>>>>> Link: ; rel=3D"action"; = action-type=3D"restart" >>>>>>>>>>> Link: ; rel=3D"action"; action-type=3D"stop" >>>>>>>>>>> ... >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> It seems that you are just adding an indirection mechanism. = Why is that >>>>>>>>>> necessary? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> With indirection mechanism i'm trying to solve issues raised = around initial version of the spec[1]. There were several issues: >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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: >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 1. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 0 >>>>>>>>> 2. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 1 >>>>>>>>>>=20 >>>>>>>>>> Best regards, Julian >>>>>>>>> Cheers, >>>>>>>>> ioseb >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> link-relations mailing list >>>>>>>>> link-relations@ietf.org (mailto:link-relations@ietf.org) = (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) = (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) = (mailto:link-relations@ietf.org) >>>>>>>>> https://www.ietf.org/mailman/listinfo/link-relations >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ioseb.dzmanashvili@gmail.com Wed Aug 28 14:04:29 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FCE21F99D0; Wed, 28 Aug 2013 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6hM4YKGYr48; Wed, 28 Aug 2013 14:04:29 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAA521F99A2; Wed, 28 Aug 2013 14:04:28 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so3189245eek.38 for ; Wed, 28 Aug 2013 14:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=VRGU9nYPL/7NMlKsjpMG0/nYEt+FX9N6E8iwlcQ2f/k=; b=OD3MNe+BXM1MFb1QyNFPuQW9943SJjAyM9moQZR2/STd92QQYhO6yzyuE/RyrraJZH zX8POHxwz8DavBgxcdTuhVaSVVqxfqvXiSymQQTlLlnyfvH8WFlpQvLrdCglLKvzrE8b 5odBdkUrcrpjfssHk7Y2ykpI6AuKs2ZHFYXOIV4wRFGAQ9w85CiOIAdueELRlVO/UgXZ RGHg/9omidsm+dlA7OoQdogU1fDN7xNqMLUzP9Lk+0U8rXq+Iu5z9eSWnQxpJLQWGc5j HtD1Aa7Y2hGM9UpGQaIJy0gskLZ4KHHAJApt6mnlhZIJJJ9TicnPpjtwwJMWJVxqKIX3 PD1w== X-Received: by 10.14.205.9 with SMTP id i9mr5007403eeo.72.1377723867725; Wed, 28 Aug 2013 14:04:27 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id r48sm40590001eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 14:04:27 -0700 (PDT) Date: Thu, 29 Aug 2013 01:04:23 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <5CAC7F65268B47BFB1CF37E4C1393382@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

<30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> Subject: Re: [apps-discuss] NEW RELATION: 'action' version update X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 21:04:29 -0000 Thank you Mike! On Thursday, August 29, 2013 at 12:02 AM, mike amundsen 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. > 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@gmail.com Wed Aug 28 14:55:06 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27321F9F2D; Wed, 28 Aug 2013 14:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.842 X-Spam-Level: X-Spam-Status: No, score=0.842 tagged_above=-999 required=5 tests=[AWL=-1.559, BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+J3F1G7DZc3; Wed, 28 Aug 2013 14:54:40 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id F393B21F9223; Wed, 28 Aug 2013 14:54:34 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c41so3211809eek.39 for ; Wed, 28 Aug 2013 14:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=a7a1vNpDFbbKKm7RWM0GHIr7TE31S6RuZA87DcF0yJE=; b=UYWmhJBKpg6I+voZ7CaH/Cg7AsRdveqmt2fsHjlLwB+3LbaJ54Q1hc5WLO6FQ3kiO7 5yK6FaQhrR/fa0uJiXdhVGNPa890mdMNxCmtokwL0GCv0rZHLPL5CW9upEQkzHifv/Ka DWvGG0pDAX0KQjOxek4Qz4z8TbX4VzM8Omx+NBpWe2Disn5QmZvdVbfFvNO/IzaDIgZE Ifgl4iNbJhPstEjQj/xl/2Wk5+alLcXqa+k3l6Fga4xhM7aOXCb0NdVcwXnvryCpB2NC lx1XI8OSwI9ezz0bQHRhekN4a5yUEXRyhGwfNDArfQP2DjBjw9AtF8R+qs6184nWpDOR 7wjg== X-Received: by 10.14.176.8 with SMTP id a8mr80143eem.12.1377726874099; Wed, 28 Aug 2013 14:54:34 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id f49sm40875868eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 14:54:33 -0700 (PDT) Date: Thu, 29 Aug 2013 01:54:28 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <7F642727A2D74D2A9FB328907D88EC79@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

- - -

- ... - 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: - - - - - - ... - 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 > > - 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 > > > > some datetime afetr which to suspend > > > .... nice candidate to re-use iCalender, BTW. > > > > > - 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 > > > > > > 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@gmail.com Fri Aug 30 00:12:13 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DB721E809F; Fri, 30 Aug 2013 00:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifSBNXgjtefK; Fri, 30 Aug 2013 00:12:13 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0C621E805A; Fri, 30 Aug 2013 00:12:12 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so701382eek.19 for ; Fri, 30 Aug 2013 00:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=mPy2n5oCl16F8HTLQDiCsFkvOe9M6XNp+z25p6y2bcA=; b=l3j3C7Xx2MQLJyNLkfXxNi5vX2fQvpCBliHRpwEnhl+NyuLS5o8ummWHqvOSmIM9ow 9Ni7Nu3P5jcs38lpkOIB6BzFDJTqGXlVJiu2YPKT1LQZFYSIPGt1lC0Ayqo+BX+AGoSS iImeHIdJNXVOVr2rx9gchk7bMtxKEd70RIyg0k7tR0N7jizW24iRXxLFVu97hiVBdxWA oGQdYACZGjUf5mxr5D38NMxj0UY4Ri9QrxLK5EhY6Z61vvY6QhGrhpt0Y9u3NW+Sq0G8 1WsOIsn0JGHcFTEAj9RSRuN2mCfjFgBBBZUHu7aGfITn+ubjFGDLqRX9O7GBza3WZHEz n9tA== X-Received: by 10.14.115.133 with SMTP id e5mr10432577eeh.27.1377846731619; Fri, 30 Aug 2013 00:12:11 -0700 (PDT) Received: from [10.131.33.142] ([213.131.60.234]) by mx.google.com with ESMTPSA id bn13sm52182377eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 00:12:10 -0700 (PDT) Date: Fri, 30 Aug 2013 11:12:08 +0400 From: Ioseb Dzmanashvili To: Mark Nottingham Message-ID: <578924E59872456BA66743C8101F9743@gmail.com> In-Reply-To: <3CC7487C-1157-4F16-ADA3-A246C9EB4B35@mnot.net> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <3CC7487C-1157-4F16-ADA3-A246C9EB4B35@mnot.net> Subject: Re: [apps-discuss] NEW RELATION: 'action' version update X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:12:13 -0000 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 wrote: > > > Now consider this link: > > > > Link: ; 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 > > > > Huh. Why not just use a link hint? E.g., > > Link: ; 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 dret@berkeley.edu Sat Aug 31 09:40:55 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36E21F8DDD; Sat, 31 Aug 2013 09:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogdFdQw8f-Dn; Sat, 31 Aug 2013 09:40:50 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 993A121F842B; Sat, 31 Aug 2013 09:40:50 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VFoE6-000087-AA; Sat, 31 Aug 2013 09:40:43 -0700 Message-ID: <52221C87.8030800@berkeley.edu> Date: Sat, 31 Aug 2013 09:40:39 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jan Algermissen Subject: Re: [apps-discuss] NEW RELATION: 'action' version update References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

<30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> In-Reply-To: <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 16:40:55 -0000 hello. On 2013-08-28 13:27 , Jan Algermissen wrote: > On 28.08.2013, at 22:02, mike amundsen 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. 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:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From mca@amundsen.com Sat Aug 31 10:00:50 2013 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D317021E80CA for ; Sat, 31 Aug 2013 10:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.807 X-Spam-Level: * X-Spam-Status: No, score=1.807 tagged_above=-999 required=5 tests=[AWL=1.886, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj6lFKTDr2ql for ; Sat, 31 Aug 2013 10:00:46 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id D803A21E80C7 for ; Sat, 31 Aug 2013 10:00:45 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so2509230wes.21 for ; Sat, 31 Aug 2013 10:00:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=5Y0xiPmpLhm9+gDesWF1A/Jo6qEZtJ9kcpxQxotoN08=; b=aClA5RcS7lt+h3AVzF+loyQa8qKs6f1sg8oQ+jETyZgnFTDuiWjj4uVzvWDMqZIObh WDWsWKDPb90ZZYadldSU+WQk7L4zexlfJ8uhe1mQHlq9mg+aNw68uf9faFjHgQxV6DsD Hwq0MFTpoBoCmWyJBk3sZRlTmhuDFKJpGgcmAdYJUR6HCCzfA6JxrzeTQdWToK37WXCc abrYTa1KrfqOG+IFWOV23AR2oqVJjkLnzsgradVKpIVm/f9GlBMdTC35kVd5M2RWNhlr 4VAUNJESETLoAjVkWbnAkJ0XvVT1eClhev2oCC5wJcbmkKdbuBhlQVM9BwQ7rznFDNIf n6GA== X-Gm-Message-State: ALoCoQlzXNcsmc3AvrUpfKMTedCnHMBxqvVjAq0NiDB14dmmsGI4abNyDR0iWUS5g2rBYVXuWkmi X-Received: by 10.180.77.49 with SMTP id p17mr6930534wiw.36.1377968444005; Sat, 31 Aug 2013 10:00:44 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Sat, 31 Aug 2013 10:00:23 -0700 (PDT) In-Reply-To: <52221C87.8030800@berkeley.edu> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com>

<30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> <52221C87.8030800@berkeley.edu> From: mike amundsen Date: Sat, 31 Aug 2013 13:00:23 -0400 X-Google-Sender-Auth: Ulg8SkVDRuMINLOOTB4_xU45hk0 Message-ID: Subject: Re: [apps-discuss] NEW RELATION: 'action' version update To: Erik Wilde Content-Type: multipart/alternative; boundary=f46d043892139dfbd304e5414730 Cc: Julian Reschke , IETF Apps Discuss , link-relations X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 17:00:50 -0000 --f46d043892139dfbd304e5414730 Content-Type: text/plain; charset=ISO-8859-1 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? 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 Sat, Aug 31, 2013 at 12:40 PM, Erik Wilde wrote: > hello. > > > On 2013-08-28 13:27 , Jan Algermissen wrote: > >> On 28.08.2013, at 22:02, mike amundsen 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. >> > > 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:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > --f46d043892139dfbd304e5414730 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

At this point, what we're di= scussing is affordance design.

I will confess that the d= esire to pack up all the information on how to activate a transition into &= quot;hints" on a LINK element creates not just an ugly affordance, but= also one needlessly difficult to use/animate. This is esp. true when machi= nes are required to "so-somewhere-else" in order to resolve the d= etails 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 abou= t the FORM-style affordance that is so unappealing to designers/developers?= =A0

</tangent>

mamund

+1.859.757.144= 9
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/= mamund
https://github.com/= mamund
http://www.linkedin.com/in/mikeamundsen

On Sat, Aug 31, 2013 at 12:40 PM, Erik W= ilde <dret@berkeley.edu> wrote:

hello.

On 2013-08-28 13:27 , Jan Algermissen wrote:

On 28.08.2013, at 22:02, mike amundsen <mamund@yahoo.com> wrote:

2) when crafting link rel values, i got good advice (I think it was from Ju= lianR?) to cast the definitions as "relations" not just "ver= bs" or "nouns." for example:
"The link relation {value} identifies a target resource that represent= s {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 ba= d 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 represe= nt 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 y= ou 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 particula= r 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 co= mmunicate 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:= dret@berkeley.edu =A0- =A0tel:+1-510-2061079 |
=A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (ISchool= ) |
=A0 =A0 =A0 =A0 =A0 =A0| http://dret.net/netdret http://twitter.com/dret |

--f46d043892139dfbd304e5414730--