> It's one action pointing to another action, so I didn't use > executesAutomationPlan as it's not pointing to an AutomationPlan. > Other than that it's semantically very similar.
Yeah... I'm not sure how I came to think the objects were identical [rubs eyes], but they're not identical on the page. Possibly the /plans/blah blah URIs (for actions) confused me, but by now I of all people should know better than to infer too much from a URI's value. New comments > This Automation Request resource itself will never executed, as it was created from an oslc_auto:TemplateDialog This is a non sequitir. It will never be executed *in this scenario*, because... *and the client will never change its state to make it eligible for execution*. > In this scenario the consumer is familiar with future actions (this was taken as a design decision when it was implemented - should this be in a specification profile?), I would be tempted to simply say that it GETs the AutoPlan *because* it's a 2.1 client and wants to see if any future actions are available, so (if present) it can offer those to the user in the authoring process. I can't actually think of any other (2.0) reason the client would GET the AutoPlan, so this has the nice side effect of justifying the GET which is (today) simply assumed to be necessary. > The consumer finds and polls the generated Automation Result suggest: generated => newly created > <plans/1/results/67890>'s oslc:action blank node's types are a oslc:Action, oslc:StopAction > <plans/1/future-stop>'s types are a oslc:Action, oslc:TeardownAction shouldn't the first have a type of oslc:TeardownAction , either instead of or in addition to oslc:StopAction ? The mismatch in type sets looks odd, although I'm not sure if that's a case of "true, but not relevant" > Automation Request specification profile of the Actions specification, it recognises this as the Automation Request interaction pattern, and therefore know that it can knowS thinking out loud: [link] for spec profile and Actions spec? We both know that the link present above is to the same document, and IIRC the AR spec profile just points off to Automation 2.1. On one hand, this is a scenario page not a spec. On the other hand, it has been hard for everyone other than you & Umberto to understand the different points in time (phases) until recently, so might be worth it to be painfully explicit here. > The consumer performs an HTTP GET on the URI that is the value of rdf:value on the oslc:ContentFromRepresentation resource: ...[diagram]... The consumer takes the representation received from that request and uses it as the request body (also setting Content-Type to the value it observed along with that body) of an HTTP POST to the value of the http:requestURI property. Clearer? (no change) The consumer performs an HTTP GET on the URI that is the value of rdf:value on the oslc:ContentFromRepresentation resource: ...[diagram]... (reworded) The consumer uses the action binding information combined with the GET response to form an Automation Request creation request message; it uses the GET's response representation as the creation (POST) request body, it uses the binding's http:requestURI property as the HTTP request-URI, and it copies the GET response's Content-Type header to the POST request. > oslc_auto producedByAutomationRequest add colon between those tokens > would have been generated as configuration time aT Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
