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
