[Oslc-Automation] OSLC Actions: Action for resource that does not yet exist: worked example

[John Arwe]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140130/2c4ebc7a/attachment-0003.html>