[Oslc-Automation] Automation Plan parameters - in vs out
Michael F Fiedler
fiedler at us.ibm.com
Wed Apr 11 16:53:47 EDT 2012
The final differentiation as discussed was as follows. You are correct
this needs to be clearer in the specification itself. I'll open an issue
for that.
Automation Plan:
paramterDefinition: The parameters as defined in the Automation Plan.
These are the valid parameters which can be supplied on the creation of an
Automtion Request for this plan. IMO, they should be read only, at least
until we address plan creation/compsition.
Automation Request:
initialParameter (maybe need a better name): Actual parameter instance
values supplied by the creator of the Request. Writeable.
Automation Result:
initialParameter: Copied from the Automation Request - represents the
parameters supplied at Request creation time. IMO, should be read only
additionalParameter: Added to the Automation Result by some actor (the
service provider or other) during execution. Distinguished from
contributions in that they are meant to be used as parameters on future
chained Automation requests. Provided in the same format as a convenience
for copying.
Other thoughts?
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
John
Arwe/Poughkeepsie
/IBM at IBMUS To
Sent by: oslc-automation at open-services.net,
oslc-automation-b cc
ounces at open-servi
ces.net Subject
[Oslc-Automation] Automation Plan
parameters - in vs out
04/05/2012 08:47
AM
My implementers are unclear as to how they should differentiate between
input and output parameter definitions from the content at [1].
Given all our iterations/gyrations on the calls, I confess I'm no longer
sure how to do so either.
I suppose we might re-use oslc:readOnly for this (if it is r/o from the
perspective of the Plan implementation, that's an input property, and the
converse), but that seems pretty dicey and prone to conflict when a
parameter definition is re-used in multiple contexts. It seems more likely
to be a property of the usage of a parameter within the context of a given
Plan (and potentially implementation).
[1]
http://open-services.net/bin/view/Main/AutoSpecificationV2?sortcol=table;up=#Resource_AutomationPlan
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120411/c0043a6c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120411/c0043a6c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic48680.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120411/c0043a6c/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120411/c0043a6c/attachment-0002.gif>
More information about the Oslc-Automation
mailing list