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: [email protected] Phone: 978-899-4720 [email protected] wrote on 07/24/2012 12:08:19 PM: > From: Charles Rankin/Austin/IBM@IBMUS > To: [email protected] > Date: 07/24/2012 12:44 PM > Subject: [Oslc-Automation] Revisiting input and output parameters > Sent by: [email protected] > > 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
