Yes, the consumer needs to know if the configuration phase succeeded or failed. But I don't think this is any different from the Automation Request pattern, where if the POST to the creation factory fail with a 4xx or 5xx status code then the consumer needs to be able to treat that as an error and not try looking for an AutomationResult to poll. (In both cases I believe you won't have a URI to proceed with, so it's impossible to proceed if the first step fails.)
The only difference is that in the deferred dialog case there are two bindings, and in the Automation case there's one. So I still don't see any problem with just removing finalStatusLocation from the deferred dialog rule and just "inheriting" the fact that an empty result from the dialog (or a 4xx or 5xx status code, if appropriate) means that the dialog failed (and therefore the config stage failed as it has no way to continue) from the fact that this is an oslc:Dialog. We can mention it explicitly if that's better, but I don't think there's any normative difference. My take is that "executing the action" consists of "one config stage + one execution stage". If it's reused the config stage that was also used for a previous action execution, fine. But the config stage on its own is only one step in executing a deferred dialog binding, so does not have a final result itself. It is only when you have combined one (any) config stage with an execution stage that you get a final result. (If you wanted a binding that merely created a template you could do that, and have oslc:finalStatusLocation oslc:Dialog on it. But that would have to be on a different action, as "create a template" has different semantics to "create a template and use it" when taken as a whole.) Do you think the failure of the config stage needs to be spelled out any more specifically than the AutomationRequest example above? If so, why? If not, would you be happy for us to just exclude the finalStatusLocation from the deferred dialog binding? 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 17/04/2014 14:31:32: > From: John Arwe <[email protected]> > To: [email protected], > Date: 17/04/2014 14:32 > Subject: Re: [Oslc-Automation] Final changes (hopefully) for Actions > spec: desiredResult -> finalStatusLocation > Sent by: "Oslc-Automation" <[email protected]> > > My take is that deferred execution has one "final result" *per phase > instance* (blech on the term, I know). The client has to know how > to find the config phase result (was the template created), *and* it > has to know (at a later point in time) how to find the result of the > executing the plan each time (execution phase). 1 config phase : n > execution phase "instances", too. The immediate execution bindings > handle the latter I think, so config phase is what's left. > It is true that this doesn't play as nicely with the statement that > the desired result is executing the action (once, by implication). > If we want to stick with this definition, the alternative I see > would be to say the config phase is simply not part of executing the > action ... maybe we call that a separate process entirely, whose > result is an optional input to the action-execution process. That's > conceptually reasonable. If the deferred execution dialog adheres > to Core's documented pattern for delegated creation dialogs, which I > think it does (the "deferred" bit is really a way of turning an > *auto request* creation dialog ... which has additional non-core > semantics ... back into a pure-Core creation dialog), then there is > no ambiguity about where that result is found (or Core has a bug). > Core doesn't assign a URI to that pattern (today), so we could > choose to fix it for all deferred dialogs (which IIRC are already > essentially Automation-specific) or we could choose to mint a new > URI if we believe there is a strong need to allow it to vary (and > hence be discoverable at run time). > I'm agnostic on which choice we make, functionallly. My inner > minimalist leans towards pointing in text to Core, done. > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > > > [image removed] Martin P Pain---04/16/2014 10:00:13 AM---I think we > need to remove the oslc:finalStatusLocation from the Deferred > Execution Dialog Interactio > > From: Martin P Pain/UK/IBM@IBMGB > To: John Arwe/Poughkeepsie/IBM@IBMUS, > Cc: [email protected] > Date: 04/16/2014 10:00 AM > Subject: Re: [Oslc-Automation] Final changes (hopefully) for Actions > spec: desiredResult -> finalStatusLocation > > > I think we need to remove the oslc:finalStatusLocation from the > Deferred Execution Dialog Interaction Pattern [1] recognition rule, > as it's not correct. The final status location (status of the > desired result) is not the result of the dialog, but of the > subsequent immediate-execution binding. > > I think that's implied by oslc:usage oslc_auto:DeferredExecution (I > can't think of a deferred execution dialog that would indicate > status any other way), so I don't think we need a oslc:finalStatusLocation > value at all, although this would be the only one without one. We could set > oslc:finalStatusLocation oslc_auto:DeferredExecution to avoid > inferring something from an absence (i.e. if a deferred dialog had > oslc:finalStatusLocation set to any other value, what would that > mean? Would it mean you could only check the status in the location > in specified, or is that an alternative to the ones specified in > the immediate-execution bindings?) But I'm starting to think that's overkill. > > Could one other person (John? Umberto?) vote between these two > options (or suggest an alternative): > Option 1. To remove the oslc:finalStatusLocation property from the > Deferred Execution Dialog Interaction Pattern [1] recognition rule. > Option 2. To replace the oslc:finalStatusLocation value with > oslc_auto:DeferredExecution in the Deferred Execution Dialog > Interaction Pattern [1] recognition rule. > > Thanks > > [1] http://open-services.net/wiki/automation/OSLC-Automation- > Specification-Version-2.1/#Template-Dialog-interaction-pattern > > > > 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 > > > [image removed] Martin P Pain---16/04/2014 13:04:37---That warning > is still intact. Martin Pain > > From: Martin P Pain/UK/IBM@IBMGB > To: [email protected], > Date: 16/04/2014 13:04 > Subject: Re: [Oslc-Automation] Final changes (hopefully) for Actions > spec: desiredResult -> finalStatusLocation > Sent by: "Oslc-Automation" <[email protected]> > > > > That warning is still intact. > > > > 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 > > > > From: John Arwe <[email protected]> > To: [email protected], > Date: 16/04/2014 12:46 > Subject: Re: [Oslc-Automation] Final changes (hopefully) for > Actions spec: desiredResult -> finalStatusLocation > Sent by: "Oslc-Automation" <[email protected]> > > > > > 4. I allowed multiple values for oslc:finalStatusLocation ([1], > [2]), in case the final status is reflected in more than one place > (to allow future interaction patterns to aid > Just make sure this doesn't open up the door to mixing single and > multi-message IPs. I don't remember if there was additional text at > this point ... IIRC there's a non-normative "there be dragons" > warning, if that survived it's probably sufficient - it's not like > we have an iron-clad proof that they cannot ever be mixed (although > we're getting close), but we have articulated specific cases where > doing so causes conflicts. > While I'm here: regrets for this week's meeting, at W3C F2F > 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 > > 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 > _______________________________________________ > 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
