The current names came about as I was creating the RDFS vocabulary. Having oslc_auto:parameter used differently for different resources is problematic. I was trying to align the Request and Result names since the usage is (almost) the same - the "input" parameters. In the Request they are provided on POST. In the Result they are can be read on GET. My preference is for 3 or 4 distinct names with accurate descriptions on usage.
Proposal: AutomationPlan: parameterDefinition AutomationRequest: parameterInstance (or inputParameterInstance) AutomationPlan: requestParameter (or inputParameterInstance), additionalParameter > John Arwe/Poughkeepsie/IBM@IBMUS > Sent by: [email protected] > > 04/20/2012 08:28 AM > > To > > [email protected], > > cc > > Subject > > Re: [Oslc-Automation] Thoughts on parameters - AutomationResult, > oslc_auto:additionalParameter to oslc_auto:parameter. > > > 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? Your assumptions is valid and I agree with the need for the additional wording/description. > > 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 > _______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
