[Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21

[Charles Rankin]

oslc-automation-bounces at open-services.net wrote on 07/25/2012 12:34:18 PM:

> From: Daniel Berg/Raleigh/IBM at IBMUS
> 
> The main reason for the separation of input and output parameters 
> was to provide an indication that the Automation Plan may "set" a 
> parameter that can be used in downstream activities which was not 
> and should not be included as an input the the request. 

As-is, the spec doesn't support this.  And, if this was the real intention 
all along, I think it got lost somewhere along the way.  I'm actually not 
aware of any would-be automation providers that support this concept 
today.  You can certainly get a final set of parameter values from some of 
them, but, again, I don't know of any that actually let you formally 
define the ones that are "officially" set at the end.  It's a good forward 
looking concept, and one that I'd actually looked at adding to a 
home-grown automation solution I developed years ago (never got 
implemented there either, <grin>).

> In my opinion the use case to check for changed input values is not 
> a common case. 

Agreed.

> The suggestion to have all parameters defined in the output which 
> includes both input and output is fine as long as within the 
> AutomationPlan it is possible to distinguish between input parameter
> definitions and output parameter definitions. More specifically I 
> need to know which parameters can be set by the user (required or 
> optional) and which ones will have a value supplied during the 
> execution of the plan (cannot be entered as an input parameter 
> value). Looking at the speck I don't believe we can make this 
> distinction based on the current definition of the 
> parameterDefinition on an AutomationPlan.
> 
> Am I missing something?

The input/output parameter distinction at the moment is only captured on 
the AutomationResult.  The (or at least my) initial thought was that 
people might be interested to see what the original set of values passed 
into the automation were, particularly if the AutomationRequest was no 
longer available.  So, inputParameters (on the AutomationResult) was added 
so that this information was available.  Then, there was the need to know 
what the current set of all visible parameters and their values were. This 
is what we ended up putting in outputParameter, except it seems to have 
gotten morphed such that it was only supplying values that were changed. 
I'm suggesting that the set of outputParameters should be the complete set 
of parameters, regardless of whether they have changed.

Any of that help clarify things?

Charles Rankin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120726/96ab6ede/attachment-0003.html>