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. In my opinion the use case to check for changed input values is not a common case. 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? Regards, Dan From: [email protected] To: [email protected], Date: 07/25/2012 12:06 PM Subject: Oslc-Automation Digest, Vol 17, Issue 21 Sent by: [email protected] Send Oslc-Automation mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://open-services.net/mailman/listinfo/oslc-automation_open-services.net or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Oslc-Automation digest..." Today's Topics: 1. Revisiting input and output parameters (Charles Rankin) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Jul 2012 11:08:19 -0500 From: Charles Rankin <[email protected]> To: [email protected] Subject: [Oslc-Automation] Revisiting input and output parameters Message-ID: <of44acfd6b.c582a214-on86257a45.00511bb0-86257a45.0058a...@us.ibm.com> Content-Type: text/plain; charset="us-ascii" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120724/f9916c9d/attachment-0001.html > ------------------------------ _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net End of Oslc-Automation Digest, Vol 17, Issue 21 ***********************************************
