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: [email protected] 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" <[email protected]> wrote on 03/04/2014 22:19:24: > From: John Arwe <[email protected]> > To: [email protected], > 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" <[email protected]> > > > 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 > [email protected] > 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
