[Oslc-Automation] Final changes (hopefully) for Actions spec: desiredResult -> finalStatusLocation
Martin P Pain
martinpain at uk.ibm.com
Thu Apr 17 09:56:50 EDT 2014
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: 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
17/04/2014 14:31:32:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 17/04/2014 14:32
> Subject: Re: [Oslc-Automation] Final changes (hopefully) for Actions
> spec: desiredResult -> finalStatusLocation
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 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 at IBMGB
> To: John Arwe/Poughkeepsie/IBM at IBMUS,
> Cc: oslc-automation at open-services.net
> 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: martinpain at uk.ibm.com
> 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 at IBMGB
> To: oslc-automation at open-services.net,
> Date: 16/04/2014 13:04
> Subject: Re: [Oslc-Automation] Final changes (hopefully) for Actions
> spec: desiredResult -> finalStatusLocation
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
>
>
> 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: martinpain at uk.ibm.com
> 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 <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 16/04/2014 12:46
> Subject: Re: [Oslc-Automation] Final changes (hopefully) for
> Actions spec: desiredResult -> finalStatusLocation
> Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
>
>
>
> > 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
> 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
>
> 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
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
> _______________________________________________
> 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/20140417/f2d60005/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/20140417/f2d60005/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/20140417/f2d60005/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/20140417/f2d60005/attachment.gif>
More information about the Oslc-Automation
mailing list