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

[Michael F Fiedler]

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 at IBMUS
> Sent by: oslc-automation-bounces at open-services.net
>
> 04/20/2012 08:28 AM
>
> To
>
> oslc-automation at open-services.net,
>
> 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
> 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/20120420/b48a192f/attachment-0003.html>