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

Wed Jul 25 17:05:33 EDT 2012

I would imagine that the majority of AutomationProviders will support 
inputParameters (I know that Rational Team Concert - JBE, Rational Build 
Forge, etc. support them) though the actual values for each parameter 
might be optional or already have a default.

Regards,
David
____________________________________________________
David Brauneis
STSM, Rational Software Delivery Automation Chief Architect
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874

From:   Pramod K Chandoria <pchandor at in.ibm.com>
To:     Daniel Berg/Raleigh/IBM at IBMUS, 
Cc:     oslc-automation at open-services.net, 
oslc-automation-bounces at open-services.net
Date:   07/25/2012 04:46 PM
Subject:        Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, 
Issue 21
Sent by:        oslc-automation-bounces at open-services.net

+1 
I am finding it difficult to map inputParameter and outputParameter 
attribute with current usage model of Rational Quality Manager (RQM) for 
Test Automation.
I do not see any use case in Test Automaton where user wants to 
differentiate between input and output parameters. 
I completely agree with what Charles recommends, outputParameter should 
contains whole bible of parameters and that solves problem of majority of 
automation provides 
Being optional, I am assuming inputParamers will be supported only by 
those special Automation providers where it really makes sense. 

Regards, 
___________________________________________________________________________ 

-|- Pramod K Chandoria 

Advisory Software Engineer 

IBM Rational, India Software Lab 

Bangalore, India | +91-80-417-77045 | +91 99805 68253 
What's new in 4.0 | Ask Question in forum | Online Help | Download RQM 4.0 

oslc-automation-bounces at open-services.net wrote on 07/25/2012 11:04:18 PM:

> From: Daniel Berg <danberg at us.ibm.com> 
> To: oslc-automation at open-services.net 
> Cc: oslc-automation at open-services.net, oslc-automation-bounces at open-
> services.net 
> Date: 07/25/2012 11:59 PM 
> Subject: Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21 
> Sent by: oslc-automation-bounces at open-services.net 
> 
> 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
> 
> [image removed] oslc-automation-request---07/25/2012 12:06:50 PM---
> Send Oslc-Automation mailing list submissions to  oslc-
> automation at open-services.net
> 
> 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
> ***********************************************
> 
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
_______________________________________________
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/20120725/9b527bbe/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120725/9b527bbe/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3624 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120725/9b527bbe/attachment-0001.gif>