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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Pramod K Chandoria <[email protected]> To: Daniel Berg/Raleigh/IBM@IBMUS, Cc: [email protected], [email protected] Date: 07/25/2012 04:46 PM Subject: Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21 Sent by: [email protected] +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 [email protected] wrote on 07/25/2012 11:04:18 PM: > From: Daniel Berg <[email protected]> > To: [email protected] > Cc: [email protected], oslc-automation-bounces@open- > services.net > Date: 07/25/2012 11:59 PM > Subject: Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21 > Sent by: [email protected] > > 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- > [email protected] > > 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 > *********************************************** > > _______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
