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
[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] 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
[email protected]
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


Reply via email to