[Oslc-Automation] Definition of "parameter"
Michael F Fiedler
fiedler at us.ibm.com
Wed Jan 18 13:51:31 EST 2012
We'll make this the first main topic for tomorrow's meeting.
What you've layed out in the RDF description of the parameter definition
and instance examples makes sense from a practical point of view. I'd like
to hear opinions of others on the "required" attribute as Charles has
described it. I'm not familiar with other specs using resource attribute
values this way, but it seems to make sense here. Resources like
ChangeRequest or TestPlan have attributes which must be present in the
resource, but this proposal takes it to the next level of indirection by
stating the resource must have an instance of this attribute with a
specific value present. Logically, it matches what you see in UIs when a
parameter is required to do something. E.g. You cannot run a certain
automated test without providing parameter values for some test input data.
My comments on the thoughts/questions in the original mail:
1) I did not specify any type for the Parameter Definition default value or
the Parameter Instance value. Pragmatically, I think the only viable
choice is String. I'm not sure if we should spec that or leave it up to
the discretion of implementers.
MF> I think we still need to allow for arbitrary value types. Spec-ing it
as string doesn't feel right. Perhaps we recommend the parameter subjects
have a type predicate to give consumers a hint as to what is expected.
2) I did not attempt to support the ordering of parameters. I don't
believe there are any likely target systems where that would be required,
but thought I'd mention it in case anyone else knew of a case where it
might be necessary.
MF> There's no ordering in RDF unless containers are used. The OSLC
guidance has been to not use containers since they are not query friendly.
My opinion is we say nothing about ordering unless we hear a strong
requirement.
3) Given the distinction above between a Parameter Definition and a
Parameter Instance, should we name the properties in Automation Plan
differently than in Automation Request and Automation Result or keep it
"parameters" and let the context be sufficient?
MF> I think we name them distinctly (parameterDefinition, parameterInstance
maybe). Do we still need to distinguish input/output under this model? I
am thinking of a case where an Automation Request is created with
parameterInstance foo=abc, but when the automation actually ran, the value
had to be modified to foo=xyz and we want to capture both in the Automation
Result. Is this a real scenario? or is it sufficient to just allow
additional paramterInstances to be added to the result as the automation
runs.
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
Charles
Rankin/Austin/IBM
@IBMUS To
Sent by: oslc-automation at open-services.net,
oslc-automation-b cc
ounces at open-servi
ces.net Subject
[Oslc-Automation] Definition of
"parameter"
01/16/2012 06:34
PM
At the last workgroup meeting there was some discussion about whether we
should define what is on the other end of a "parameter" property or leave
it up to implementations. I'd like to revisit that discussion. I'm of the
opinion that we should provide a minimally useful definition that
implementers could extend if necessary. One of the key scenarios that we
want to enable with this first version of the specification is the
"execution" scenario [1]. I'm concerned about the viability of this
scenario without having a minimally useful definition of parameters. To
that end, I'd like to take a stab at an initial representation for others
to throw darts at. My RDF-Fu is weak, so please be kind. :)
There are at least two different parameters in question. One is on an
Automation Plan and provides the name and constraints on possible input
values. The other is associated with Automation Requests and Automation
Results and represents the mapping of a specific value to a specific named
parameter. For lack of better names, I'm going to call the former a
Parameter Definition and the latter a Parameter Instance. Let's start with
the Parameter Definition. To provide a minimally useful Parameter
Definition I think we need at least two pieces of information (possibly
represented as three pieces of data). The first is simply the name of the
parameter. The other is an indication of whether the parameter must be
specified in order for the automation to be successfully executed. One
mechanism for this is to indicate a "default value" to be used if none is
provided. The presence of this also provides some potentially useful
information to those looking at an Automation Result, as they can see if
the value provided was different than the default. It isn't clear to me
that the absence of this data necessarily means that the parameter is
required. To that end, another option is to have a "required" property
that indicates whether the parameter must be specified. Without further
ado. let's take a stab at how this might look ( in Turtle).
@prefix ap: <http://somewhere.com/oslc-automation-provider> .
ap:plan1 oslc_auto:parameter _:parm1 .
ap:plan1 oslc_auto:parameter _:parm2 .
ap:plan1 oslc_auto:parameter _:parm3 .
_:parm1 foaf:name "must_have" .
_:parm1 oslc_auto:required oslc_auto:required_yes .
_:parm2 foaf:name "might_have" .
_:parm2 oslc:defaultValue "some value" .
_:parm2 oslc_auto:required oslc_auto:required_no .
_:parm3 foaf:name "may_have" .
_:parm3 oslc_auto:required oslc_auto:required_no .
The first definition indicates there is a required parameter with a name of
"must_have". The second definition indicates there is an optional parameter
with a name of "might_have", which if no value is specified a default value
of "some value" will be used. The third definition indicates there is an
optional parameter with a name of "may_have", which if no value is
specified, no default value will be provided.
The information needed to define a Parameter Instance is a little less than
for a Parameter Definition. All that is required is the name of the
parameter and the value of the parameter. While these could be specified
as direct "name=value" strings, I think it is better to separate the name
from the value. So, an Automation Request specifying information for the
plan above, might have parameters as such.
@prefix ap: <http://somewhere.com/oslc-automation-provider> .
ap:req1 oslc_auto:parameter _:parm1 .
ap:req1 oslc_auto:parameter _:parm2 .
_:parm1 foaf:name "must_have" .
_:parm1 rdf:value "here you go" .
_:parm2 foaf:name "may_have" .
_:parm2 rdf:value "more information" .
This indicates that there are two parameters specified one with a name of
"must_have" and corresponding value of "here you go", and another with a
name of "may have" and a corresponding value of "more information".
A few more thoughts/questions before I finish.
1) I did not specify any type for the Parameter Definition default value or
the Parameter Instance value. Pragmatically, I think the only viable
choice is String. I'm not sure if we should spec that or leave it up to
the discretion of implementers.
2) I did not attempt to support the ordering of parameters. I don't
believe there are any likely target systems where that would be required,
but thought I'd mention it in case anyone else knew of a case where it
might be necessary.
3) Given the distinction above between a Parameter Definition and a
Parameter Instance, should we name the properties in Automation Plan
differently than in Automation Request and Automation Result or keep it
"parameters" and let the context be sufficient?
That's enough for now. Have at it. :)
[1] http://open-services.net/bin/view/Main/AutomationExecutionScenario
Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
More information about the Oslc-Automation
mailing list