[Oslc-Automation] Revisiting input and output parameters

[Max Vohlken]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120726/c4fbeb54/attachment-0003.html>