[Oslc-Automation] first cut at split of auto request from fixed body is live

Martin P Pain martinpain at uk.ibm.com
Fri Apr 4 09:03:40 EDT 2014


All,

> - Added words to the "not always single message" IPs (i.e. 
> Automation-based ones) saying how the client determines "status of 
> its goal", but otherwise left it based on Core CF. 
> Please review - I'd like to put the "enter convergence/ask for Core 
> review" item on next meeting's agenda, since I fully expect to have 
> examples and diagrams caught up this week. 

I tweaked the wording to:

The client's goal is to execute the Automation Request, not just to create 
it. The status of this goal is determined using the corresponding 
Automation Result's [state and verdict 
properties](#State-and-Verdict-properties), as would be the case
with any other Automation Request, not by using the HTTP status codes. 
[Automation permits 
both](#Asynchronous-and-Synchronous-Automation-Execution) 
single-message and multiple-message interactions, but the client **MUST** 
use
the state and verdict for determining the [status of the client's 
goal](/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Interaction-patterns) 
when the HTTP status codes indicate that the creation was successful.

(Clarified what the client's goal is, moved "determining" before the link, 
and clarified what the HTTP status codes are indicating, in contrast to 
"the client's goal". Also made it a separate paragraph.)

(An alternative with fewer changes could be:

The status of the client's goal is determined using the corresponding 
Automation Result's [state and verdict 
properties](#State-and-Verdict-properties), as would be the case with any 
other Automation Request.  [Automation permits 
both](#Asynchronous-and-Synchronous-Automation-Execution) 
single-message and multiple-message interactions, but the client **MUST** 
use the state and verdict for determining the [status of the client's 
goal](/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Interaction-patterns) 
when the HTTP status codes indicate that the creation was successful.)

> - Changed "creation factory IP" to be ONLY a "automation CF IP" ... 
> the general Core IP would contain ambiguities, and we only need this
> constrained form, so KISSed it. 

Looking at this, I don't like the fact that there's nothing that a later 
definition of a CF IP in Core could point at to say "when the CF bindings 
match X, it is a multi-message IP, and the subsequent messages are defined 
by other specifications (link to Automation)".

Having talked about this with John, we suggest we have a way (in core) to 
identify how IPs report the status of the action (that is, of the 
consumer's goal), so we have something in scope of core that doesn't tie 
us into the same sort of problem that we already have with the 
creation-tied-to-execution semantics? (the 
oslc-automation:DeferredExecution/ImediateExecution wouldn't be enough, as 
both of them are multi-message patterns.)

How our existing IPs report the action's status:
The 3 HTTP IPs = the HTTP status code 
delegated UI for immediate execution = status code + oslc:result 
Auto req = Automation result status
Delegated UI for deferred execution: config phase = del UI oslc:results + 
GET status; execution phase depends on the immed exec binding 
AutoReq CF (sic) = Automation result status

So the HTTP IPs would include in their recognition rule something like "at 
least one oslc:interactionStatus property MUST have the value 
http:StatusCode", and then define (possibly through referring to another 
section or an appendix) what each status code means (currently listed in 
Appendix A, I believe)



Other than that everything looks good.

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 
03/04/2014 22:19:24:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Date: 03/04/2014 22:20
> Subject: Re: [Oslc-Automation] first cut at split of auto request 
> from fixed body is live
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> > Q1:  are we going to switch to parameter instance or not? 
> now done and live (spec), examples + diagrams to come 
> 
> > Q2:  should we define ContentFromRepresentation as a subclass of 
> cnt:Content ? 
> no change, per the email discussion 
> 
> > Q3: are we going to change the Automation Request pattern's 
recognition rule
> now live 
> 
> > Q4: the immediate action dialog binding looks a bit odd 
> no change, per the email discussion 
> 
> > Q5: how are we going to use the ODT content going forward, 
> Martin to update that and work it in to an appendix or examples or 
> scenarios page 
> 
> > Q6: Apropos ... single vs multi-message patterns, I'm not sure 
> what the expectation is on Creation Factory in Automation 2.1. 
> I drafted something up; the usual search ("Arwe:" + red) in both 
> documents will show the changes.  I may sand the wording more 
> (others are welcome to too), but as of now I think I finally got it 
> right-enough.  In summary: 
> - Changed "creation factory IP" to be ONLY a "automation CF IP" ... 
> the general Core IP would contain ambiguities, and we only need this
> constrained form, so KISSed it. 
> - Added words to the "not always single message" IPs (i.e. 
> Automation-based ones) saying how the client determines "status of 
> its goal", but otherwise left it based on Core CF. 
> Please review - I'd like to put the "enter convergence/ask for Core 
> review" item on next meeting's agenda, since I fully expect to have 
> examples and diagrams caught up this week. 
> 
> > Q7:  Auto 2.1's immediate bindings section is silent on whether or 
> > not CF is valid; this answer likely flows from Q6's answer. 
> Given the constraints I placed on the new definition, it is valid 
> and so I added it to the white-list of immediate bindings. 
> 
> New: I spotted one place (exactly one of n>5, based on searches) 
> where Automation 2.1 used oslc_auto:DeferredExecution as a value of 
> rdf:type, and changed that from rdf:type to oslc:usage, so it now 
> matches all the other places I found. 

> 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/20140404/c005a715/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/20140404/c005a715/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/20140404/c005a715/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/20140404/c005a715/attachment.gif>


More information about the Oslc-Automation mailing list