Thanks Mike and John for the response. I agree that It is AutomationResult that is where user will look for the final parameters. However We need a bridge to bring those values forward from AutomationRequest to the end AutomationResult. Right now there is a gap to hold values within AutomationRequest until AutomatiuonRequest is created. Note that automation participant might contribute outputParameters to either AutomationRequest or AutomationResult depending upon the state of Automation execution, Rational Quality Manager rely on Automation Request during execution to generate Automation Result at the end.
-|- Pramod Chandoria From: John Arwe <[email protected]> To: community <[email protected]>, [email protected], [email protected] Date: 10/15/2012 06:34 PM Subject: Re: [Oslc-Automation] [oslc] OSLC Automation specification preparing to enter finalization phase Sent by: "Oslc-Automation" <[email protected]> > I noticed that Automation Request does not have > oslc_auto:outputParameter property, similar to Automation Result. > This limits the capability to maintain variables till Automation > Result has been created. I know it have oslc_auto:inputParameter > property, but that is read only, often copy from Automation plan. "Limits" overstates the case; there is no MUST NOT to this effect. As Michael set, this is a question of where most consumers would expect to look for it. As the resident multi-typing lover, I'll add another option (which may/not work in your particular implementation's case, hence 'option'): make your Request also be the corresponding Result. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
