Following on from the discussion about the scenario/interaction pattern of "delegated UI dialog to execute action later" for resources that don't exist - that scenario was already covered in "scenario C" at: http://open-services.net/wiki/automation/Action-dialog-scenarios/ although admittedly it is a complex scenario that the current spec does not solve (or at least we haven't yet described a way that it solves it).
Kind regards, 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 21/11/2013 09:40:01: > From: Martin P Pain/UK/IBM@IBMGB > To: John Arwe <[email protected]>, > Cc: [email protected] > Date: 21/11/2013 09:40 > Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF > Sent by: "Oslc-Automation" <[email protected]> > > Responses inline. > > > > Kind regards, > > 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: [image removed] and within IBM on: [image removed] > > [image removed] > > > > > 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 20/11/2013 14:13:01: > > > From: John Arwe <[email protected]> > > To: [email protected], > > Date: 20/11/2013 14:13 > > Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF > > Sent by: "Oslc-Automation" <[email protected]> > > > > action:request [ a oslc:Dialog ] seems like it would work, and > > certainly re-uses existing concepts & artifacts in what looks like a > > completely sensible way. > > > > Are these scenarios heading to a wiki page? > > They are now here: http://open-services.net/wiki/automation/Action- > dialog-scenarios/, linked to from the teardpown and Auto actions pages. > > > > I'm a *bit* confused when you say that scenarios B and C are > > "specific to the Automation profile". > > It is true that the Automation *spec* defines what usage=template > > means. Automation is the only spec I'm aware of that overloaded > > resource creation with additional semantics (flogs self Again for > > missing that in 2.0 review phase), but I'd hope that we're drafting > > the usage URI in such a way that another spec Could re-use it if a > > similar situation arose. Being defined by the Automation spec alone > > therefore does not tie templates to the Automation profile. > > > > Put another way: if we assume that action:request [ a oslc:Dialog ] > > is the syntax, and the semantic of action:request is "contains > > instructions for executing the Action", then if a particular set of > > instructions includes usage=template do we consider that an error > > (since usage=template conflicts somehow with ... I'm not sure what, > > but maybe I'm missing something) ? > > It conflicts with the interaction pattern that says "submitting this > dialog executes the action". However, I'm not necessarily saying > that this is an error. Perhaps it's better that we rely on the > oslc:usage value(s) on the dialog to define the interaction pattern > (in which case we need one for "action dialog") so then the template > dialog usage can define the template-based interaction pattern. > Right now I quite like the idea of that (as long we we're not > implying things by a value _not_ being present, as we've ended up > doing with creation dialogs). > > ... > > > > We could, for example, create usage URIs like "execute immediately" > > for actions, and require 1:* usage URIs on action dialogs; all URIs > > on a given dialog must be "compatible" in the same sense that > > Automation uses to enable logical subclassing of verdicts/states, > > and a client must not use a dialog unless it understands at least > > one of those URIs. > > > > That allows profiles (defined in Core, or elsewhere) to define > > dialogs with different semantics without having to worry about > > (compliant) clients getting unexpected results. > > Sounds good. > > > One such profile might be called "deferred execution". For the > > moment, I'll assume that's defined separately from the Automation > > profile (combining them later if we decide they must be is always > > easier than untangling things after the fact). What we need for > > this is actually 2 dialogs: one to create the template, and one that > > accepts a template as pre-fill (using existing terminology) and > > executes it immediately (a standard creation dialog that accepts > > pre-fill; we need to think through what the interaction pattern > > (responses) should be). > > There are two forms (at least) of deferred execution: one where the > user is present at the "later" time, and one where they are not. For > the latter, having a separate dialog would not work - you need a > creation factory (or some other defined interaction/request). > > In my previous email I said "I think any "execute later" scenarios > are substantially different - they need to pick a particular > implementation (e.g. AutoPlans, ResourceShape) by which it will be > executed at the later time". One of those implementations for the > "later" interaction/request could be a dialog, for the cases where a > user is present (which is what you have described briefly in your > previous paragraph). > However, for cases where there is no user present at the later time > (such as in the virtual service concrete/example scenario for > teardown) that later interaction needs a defined interaction > pattern. For flexibility, I would suggest leaving that interaction > pattern open in the same way as the initial Action's interaction pattern is. > > In other words, the "execute later" (with dialog) steps would flow > something like this: > 1) Display the "execute later" dialog (e.g. AutoRequest template dialog) > 2) Use the return value of the dialog to retrieve/generate the > request body for the appropriate "later" interaction pattern is for > (e.g. request and store the AutoRequest template) > 3) At the later time, follow the steps of the appropriate "later" > interaction pattern (e.g. submit the AutoRequest template to the > creation factory that is pointed to from the http:requestURI of the Action). > > This allows us the same flexibility for execution later as we have > for execution now, but with a way to use dialogs to generate the request body. > > But the whole interaction pattern is incomplete without a defined > "later" interaction pattern. This is why I said "they need to pick a > particular implementation (e.g. AutoPlans, ResourceShape) by which > it will be executed at the later time" and "(B) and (C) are specific > to Automation profile" (as the way I wrote them they are using the > automation interaction pattern at the "later" stage). > So we either: > 1) leave the whole of the "execute later" dialog-based interaction > pattern to individual implementation type definitions, > or > 2) we define a generic framework which generic clients can use to > execute any interaction pattern, on to which implementation type > definitions can add specifics. (But this would probably constrain > those implementation types/interaction patterns too much). > > This is the main point I want to discuss at this point. Does my > description of it make sense? > > > We *could* define a single "execute > > immediately" interaction pattern that works for both cases, I > > think...strawman off the cuff would be: > > > > 200 or 204 = succeeded already; poll the resource being acted upon > > to find current state. > > 202 = queued for execution (accepted but not yet completed). > ... > > There's an argument to be made that > > any HTTP client already MUST deal with 202 anyway > > For now my only comment here is to remember that this return data is > the result of a delegated dialog, not an HTTP request. While we > could use the http RDF vocab to encode this information in JSON-LD > (and that might not be a bad idea) we don't already have an HTTP > response context here - we would be adding it anew. > > > Automation 2.1 could require that implementations support both > > Automation Plans as implementations and template dialogs (in which > > case maybe it is just one Automation profile), or it could treat > > them separately. Personally I lean toward flexibility. > > 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 > > > Original message in full: > > "Oslc-Automation" <[email protected]> wrote > on 20/11/2013 14:13:01: > > > From: John Arwe <[email protected]> > > To: [email protected], > > Date: 20/11/2013 14:13 > > Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF > > Sent by: "Oslc-Automation" <[email protected]> > > > > action:request [ a oslc:Dialog ] seems like it would work, and > > certainly re-uses existing concepts & artifacts in what looks like a > > completely sensible way. > > > > Are these scenarios heading to a wiki page? > > > > I'm a *bit* confused when you say that scenarios B and C are > > "specific to the Automation profile". > > It is true that the Automation *spec* defines what usage=template > > means. Automation is the only spec I'm aware of that overloaded > > resource creation with additional semantics (flogs self Again for > > missing that in 2.0 review phase), but I'd hope that we're drafting > > the usage URI in such a way that another spec Could re-use it if a > > similar situation arose. Being defined by the Automation spec alone > > therefore does not tie templates to the Automation profile. > > > > Put another way: if we assume that action:request [ a oslc:Dialog ] > > is the syntax, and the semantic of action:request is "contains > > instructions for executing the Action", then if a particular set of > > instructions includes usage=template do we consider that an error > > (since usage=template conflicts somehow with ... I'm not sure what, > > but maybe I'm missing something) ? The reason we needed > > usage=template is that there is a semantic "create means create now" > > carried by creation factories in general, but *the knowledge that > > the dialog was for a creation factory* came from following a > > oslc:creationDialog link in a service provider document, a context/ > > semantic that Actions does not have. I think this is the reason > > Steve suggested calling these "action dialogs", to clearly > > distinguish them (and along the way give us the opportunity to > > define the semantics differently if needed). > > > > We could, for example, create usage URIs like "execute immediately" > > for actions, and require 1:* usage URIs on action dialogs; all URIs > > on a given dialog must be "compatible" in the same sense that > > Automation uses to enable logical subclassing of verdicts/states, > > and a client must not use a dialog unless it understands at least > > one of those URIs. > > > > That allows profiles (defined in Core, or elsewhere) to define > > dialogs with different semantics without having to worry about > > (compliant) clients getting unexpected results. > > > > One such profile might be called "deferred execution". For the > > moment, I'll assume that's defined separately from the Automation > > profile (combining them later if we decide they must be is always > > easier than untangling things after the fact). What we need for > > this is actually 2 dialogs: one to create the template, and one that > > accepts a template as pre-fill (using existing terminology) and > > executes it immediately (a standard creation dialog that accepts > > pre-fill; we need to think through what the interaction pattern > > (responses) should be). We *could* define a single "execute > > immediately" interaction pattern that works for both cases, I > > think...strawman off the cuff would be: > > > > 200 or 204 = succeeded already; poll the resource being acted upon > > to find current state. > > 202 = queued for execution (accepted but not yet completed). HTTP > > says the response payload contains a "monitor" in this case, but not > > what a monitor is - left completely open; we could say that the > > monitor (if you're using our usage URI) SHOULD be an Automation > > Request, with a Location header (allowed by HTTP, but no meaning > > assigned to that in HTTP). IF the client wants to know when/if the > > request completes (and its ultimate status), THEN the client needs > > to poll the monitor resource (no query, no service provider needed, > > just GET the Location URI) and use the state/verdict properties in > > the result per Automation 2.0. The provider is required to clean > > these up w/o any client DELETE request (my strawman - not the > > client's fault that the server queues the request, the client wasn't > > really Trying to create some new resource it would be responsible for). > > > > All other status codes exactly as HTTP uses them. > > Particular implementations might never return the 202, but clients > > still need to cope with 202. I would not be averse to giving "202 > > capable" implementations their own usage URI, if the perceived > > burden on clients is too high. There's an argument to be made that > > any HTTP client already MUST deal with 202 anyway, possibly by > > treating it as a generic 2xx, thus ignoring all the polling/monitor > > specifics, but I'd bet that no all are correctly coded in practice. > > Automation 2.1 could require that implementations support both > > Automation Plans as implementations and template dialogs (in which > > case maybe it is just one Automation profile), or it could treat > > them separately. Personally I lean toward flexibility. > > 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 > _______________________________________________ > 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
