[Oslc-Automation] Revisiting input and output parameters

[Pramod K Chandoria]

+1 for executionVariables name. This name actually reflect what it may 
represent.

-|- Pramod Chandoria




From:   Max Vohlken <mvohlken at us.ibm.com>
To:     Charles Rankin <rankinc at us.ibm.com>
Cc:     oslc-automation at open-services.net, 
oslc-automation-bounces at open-services.net
Date:   07/26/2012 11:05 PM
Subject:        Re: [Oslc-Automation] Revisiting input and output 
parameters
Sent by:        oslc-automation-bounces at open-services.net



I agree with Charles that the outputParameters should be the total set of 
parameters that the service provider is maintaining as part of the 
execution of the job. If a jobs is still running I expect outputParameters 
to also contain the values of all of the parameters at that point in time. 
Once the job has finished I expect the outputParameters to be the values 
of all of the parameters at the end of the execution. 

On a related note I'm also not a big fan of the name "outputParameters" 
for this. When I have the result of an automation job I expect to find a 
way to get all of the settings that contributed to the result. I'm not so 
sure I would call them paramaters at this point. The definition of 
parameter is "a variable that must be given a specific value during the 
execution of a program or of a procedure within a program". So when 
starting a job it makes sense to call the settings that are required at 
the start of a job to be called parameters. But during the execution of a 
job the settings are no longer parameters but instead they are just the 
variables or settings maintained by the execution engine. So is a name 
like "executionVariables" a better name?

Max Vohlken
IBM
Rational Software Division
Advisory Software Engineer
550 King St.
Littleton, MA 01460
Email: mvohlken at us.ibm.com
Phone: 978-899-4720


oslc-automation-bounces at open-services.net wrote on 07/24/2012 12:08:19 PM:

> From: Charles Rankin/Austin/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 07/24/2012 12:44 PM
> Subject: [Oslc-Automation] Revisiting input and output parameters
> Sent by: oslc-automation-bounces at open-services.net
> 
> When looking at the current wording of inputParameter and 
outputParameter for AutomationResult [1], it appears as though a parameter 
may only appear as an outputParameter if either it wasn't in the set of 
inputParameters or  it has a value different than specified on the 
inputParameter.  I question whether this is the intended and desired 
behavior?  I believe the most common use case here will be to examine the 
entire set of "output" parameters from an automation, particularly so for 
a "chaining" scenario.  As the spec is presently worded, I believe the 
user will need to do a merge between the inputParameters and 
outputParameters to get the complete set of parameters. To that end I 
would like to suggest that we change the meaning of outputParameter to 
indicate that it will be the total set of parameters, whether changed or 
not.  In the case where a user is particularly interested in whether a 
parameter has changed since the beginning of the automation, they can 
still make a comparison of the values. 
> 
> I think this will actually make things easier on service providers as 
well.  I believe that most take a snapshot of the input parameters and 
then maintain the current set of all parameter values, which aligns with 
what I'm recommending. 
> 
> One interesting corner case is what happens to a parameter, A1, that 
starts out with an initial value of "foo", then gets updated to a value of 
"bar", and then subsequently gets changed back to "foo".  With our current 
wording, would A1 be in the outputParameters at the end of the execution, 
as it has changed values during the execution, but now has the same value 
as it initially did?  With my recommended change, it will always be in the 
outputParameters with it's current value. 
> 
> On a side note, I was initially thinking about this with respect to a 
Build Forge service provider implementation for Automation.  Build Forge 
(unlike many/most other tools) does not save the initial set of parameter 
values.  So, in its present form, will not be able to accurately generate 
the inputParameters.  As the spec is currently worded, it would not be 
able to accurately generate the outputParameters either.  With my 
recommended change, Build Forge could at least provide an accurate 
representation for outputParameters.  :) 
> 
> Off-hand, I think it is probably better to force the issue one way or 
the other, so that outputParameters either have all parameters or only 
those that are new or have changed.  Softening the wording to "allow" 
outputParameters to have unchanged parameters doesn't seem to directly 
help the consumer very much, in my opinion, and may just confuse them. 
> 
> Thoughts? 
> 
> [1] 
http://open-services.net/bin/view/Main/AutoSpecificationV2?sortcol=table;up=#Resource_AutomationResult 

> 
> Charles Rankin_______________________________________________
> 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


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