[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