Okay, assuming some provides will care about input parameters whereas other not. I think we need to adopt a flexible way so it works either way for both type of providers and also satisfy the common requirement of "total set of parameters" irrespective of it's origin or modification.
Regards -|- Pramod Chandoria David N Brauneis <[email protected]> wrote on 07/26/2012 02:35:33 AM: > From: David N Brauneis <[email protected]> > To: Pramod K Chandoria/India/IBM@IBMIN > Cc: [email protected], oslc-automation-bounces@open- > services.net > Date: 07/26/2012 02:35 AM > Subject: Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21 > > 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], oslc-automation- > [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 > > [image removed] > > 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 > > [image removed] > > > > > > [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
