[Oslc-Automation] Revisiting input and output parameters

[Charles Rankin]

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-0003.html>