[Oslc-Automation] Final changes (hopefully) for Actions spec: desiredResult -> finalStatusLocation
John Arwe
johnarwe at us.ibm.com
Thu Apr 17 09:31:32 EDT 2014
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
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 IBM
Find me on: LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM
Connections:
https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891b7f
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
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 IBM
Find me on: LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM
Connections:
https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891b7f
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140417/816f8add/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140417/816f8add/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20551339.jpg
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140417/816f8add/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20093508.jpg
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140417/816f8add/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20128248.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140417/816f8add/attachment-0001.gif>
More information about the Oslc-Automation
mailing list