[Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21
Pramod K Chandoria
pchandor at in.ibm.com
Wed Jul 25 17:14:30 EDT 2012
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 <brauneis at us.ibm.com> wrote on 07/26/2012 02:35:33 AM:
> From: David N Brauneis <brauneis at us.ibm.com>
> To: Pramod K Chandoria/India/IBM at IBMIN
> Cc: oslc-automation at open-services.net, oslc-automation-bounces at 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: 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
>
> [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]
>
>
>
>
>
> 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/20120726/f37e594e/attachment-0003.html>
More information about the Oslc-Automation
mailing list