[Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21

[Daniel Berg]

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:	oslc-automation-request at open-services.net
To:	oslc-automation at open-services.net,
Date:	07/25/2012 12:06 PM
Subject:	Oslc-Automation Digest, Vol 17, Issue 21
Sent by:	oslc-automation-bounces at open-services.net



Send Oslc-Automation mailing list submissions to
		 oslc-automation at open-services.net

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
		 oslc-automation-request at open-services.net

You can reach the person managing the list at
		 oslc-automation-owner at open-services.net

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 <rankinc at us.ibm.com>
To: oslc-automation at open-services.net
Subject: [Oslc-Automation] Revisiting input and output parameters
Message-ID:

<OF44ACFD6B.C582A214-ON86257A45.00511BB0-86257A45.0058A6CB at 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
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


End of Oslc-Automation Digest, Vol 17, Issue 21
***********************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120725/8a0fc475/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120725/8a0fc475/attachment.gif>