In http://open-services.net/pipermail/oslc-automation_open-services.net/2012-April/000130.html I think you are saying
> Automation Plan: paramterDefinition: is an input (definition, not value, i.e. more like an input form def) > Automation Request: initialParameter is an input (value that would be filled into a form input field) > Automation Result: initialParameter: is an input (copy of a value that was filled into a form input field earlier in time) > Automation Result: additionalParameter: is an output One implication I see in this regime is that an Automation Request server implementation has no way within the Automation spec to add "parameters". The wg may be broadly OK with this, may not be. If we have or wish to allow implementations where each resource type is served by different tools, I could imagine that the AReq tool might add "environment variables" (R/O from the point of view of the AP requesters, configured locally to the AReq owning tool, and quite possibly not part of the APlan-as-defined by the APlan tool). If we have no in-scope scenarios that need this, I'm fine to leave it out; simple enough to see how I'd add it in later. Carefully re-reading your AReq description, I'm not sure if the intent is to allow this case by having the AReq owner simply add in additional initialParameter predicates. If that is the intent, also fine. I don't have a specific implementation in mind that knows it needs that ability, it just seems like a common pattern so I'm thinking through how an implementation would address it if/when the need became concrete. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
