[Oslc-Automation] Automation Plan parameters - in vs out

[John Arwe]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120412/9a9c5506/attachment-0003.html>