> 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
