[Oslc-Automation] Thoughts on parameters - AutomationResult, oslc_auto:additionalParameter to oslc_auto:parameter.

[John Arwe]

> 3) In the definition of AutomationResult, I suggest we changle 
> oslc_auto:additionalParameter to oslc_auto:parameter.  One 
> assumption I'm making is that these will be the complete list of all
> parameters (and values) being used at the time the GET was 
> processed.  If that assumption is valid, then I think we should also
> add some additional wording to the description to indicate so.  If 
> it isn't valid, then are there any assumptions a user can make with 
> respect to these parameters/values? 

Does this also imply removing oslc_auto:initialParameter ?
If we keep two buckets o' parameters, there is a need to differentiate 
clearly which bucket any single parameter belongs in (plus, is that choice 
XOR vs OR); otherwise clients will always have to search both, and I'm 
lost on what the value is of having two buckets.

*If* in some scenarios code needs to look at a Result and "figure out" 
which are inputs (user-provided-explicitly vs others) vs outputs, it's not 
clear to me how clients are intended to do that.  I can make some 
inferences perhaps (dependent on the answers to some of the parallel 
threads perhaps), but I find no existing spec text to support/refute the 
validity of those inferences.  E.g. I could go back to the Plan, look at 
the parameter definitions, and (dep on other answers) perhaps know which 
of the response's parameters were user-specified.  Not sure about how or 
differentiate between defaulted-inputs, other-inputs, and outputs however. 
 So it's a 2-part question: first, do any scenarios require this, and (if 
it is required) second can code reliably do so based solely on what's 
written?

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/20120420/2785ee22/attachment-0003.html>