The additionalParameter scenario is primarily for chaining. I agree hasContribution could be used as will and making the contribution a parameterInstance is a nice touch.
The question for the workgroup is: is it sufficient to put the additional parameters in the contributions? or is there value in continuing to call them out explicitly for chaining scenarios? Encouraging to get all of this feedback from a real implementation. Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170 John Arwe/Poughkeepsie /IBM@IBMUS To Sent by: [email protected], oslc-automation-b cc ounces@open-servi ces.net Subject [Oslc-Automation] output parameters 04/05/2012 08:59 AM My implementers have some output parameters. They read the spec and see a "veritable cornucopia" of places/ways to expose them (and I suggested another). It appears we're going to need some guidance here, or maybe it's common patterns. But the more variations there are, the more a generic Automation client is going to have to be coded to deal with. Plan: parameter definitions ... probably ok. Request: initial parameters ... probably ok. Result: oslc_auto:initialParameter = input = not confusing oslc_auto:additionalParameter = bit unclear, sounds like this is for chaining but could be used for outputs oslc_auto:hasContribution = this was my suggestion; stick a parameterInstance in a contribution. Interesting that people outside the wg never even considered this as an option - again, terminology may need some context for consumability. 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
