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

Martin P Pain martinpain at uk.ibm.com
Thu Jan 30 12:44:38 EST 2014 

> It will never be executed *in this 
> scenario*, because... *and the client will never change its state to
> make it eligible for execution*. 

The client cannot change its oslc_auto:state to make it eligible, as its 
oslc_auto:state is already set to oslc_auto:new, as that is what the 
provider wants submitted to the creation factory. There is no spec'd way 
to make this exact request resource (at this exact URI) eligible for 
execution. The provider has decided that this resource is not eligible for 
execution (because it was created by a template dialog), and it has not 
exposed this in the data as there is no way allowed by the spec to 
advertise this in the data. Therefore there is nothing about the data that 
can be changed to make it eligible for execution. There's nothing to stop 
the provider doing something provider-specific, but what I'm wanting to 
get across is that this is non-eligible, and that there is no spec'd way 
to make it eligible.

For now I've changed it to "This Automation Request resource itself is not 
eligible for execution", which hopefully covers both our points. (Although 
I'm not sure we introduce the term "eligible for execution" anywhere. 
Perhaps we need to include in in the Auto spec's discussion of template 
dialogs.

All other suggestions are good, I've edited the page to include them. 
Thanks.

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
30/01/2014 14:49:44:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Date: 30/01/2014 14:49
> Subject: Re: [Oslc-Automation] OSLC Actions: Action for resource 
> that does not yet exist: worked example
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> > 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 
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140130/286e65b6/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140130/286e65b6/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140130/286e65b6/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140130/286e65b6/attachment.gif>

More information about the Oslc-Automation mailing list