[Oslc-Automation] Definition of "parameter"
Charles Rankin
rankinc at us.ibm.com
Mon Jan 23 11:10:21 EST 2012
Hi, Paul. Thanks for the feedback. I hadn't really thought about the idea
of requiredness being specified via the relationship name. That's
interesting. I've always thought about "required" as just being one of
possibly many constraints on the parameter (other's might be the range of
it's values, how many times it could be specified, mandatory
inclusion/exclusion of other parameters based on specifying this parameter
or some value of it, etc.). Having said that, most (if not all) the other
types of constraints are unlikely to every be spelled out in a future
version of this spec. My only concern is that we don't add more types of
constraints to the relationship name. I'd hate to see something like
"hasSingletonParameter" or "requiresMultiInstanceParameter". That seems
highly unlikely, so I think I'm ok with specifying the requiredness via the
relationship name. I'm interested in other people's views on this.
A few other quick comments from your example.
1) You explicitly typed the parameter resource. I'm fine with that.
2) You used dcterms:title to indicate the "name" of the parameter. I had
looked at that, but the description of dcterms:title felt "off". I had
used foaf:name. Granted the "foaf" domain seems to imply there's a person
somwhere there, but the description of foaf:name didn't seem to imply that.
Nevertheless, I don't have any strong feelings about the actual property we
use here.
3) Your examples shows a parameter definition resource being used across
multiple Automation Plans. That's an intriguing idea, but not one that I
think we'll see in practice. The only system I know of that even defines
the parameters outside of the scope of the Automation Plan itself is Build
Forge, and, even there, I don't think the implementation would choose to
expose them as common parameter definitions.
Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Paul McMahan/Raleigh/IBM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Charles Rankin/Austin/IBM at IBMUS |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-automation at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|01/22/2012 11:43 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [Oslc-Automation] Definition of "parameter" |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Charles,
Thanks for "kicking it up a notch" on this important topic. Treating each
parameter as a blank node makes sense to me.
At the risk of splitting hairs, I tend to think of parameters as being
required in relation to a particular automation plan instead of having an
intrinsic "requiredness" on their own. For example, in a single RDF model
you might have different automation plans that use the same parameters.
The parameters might be required for one plan but not for the other. So
whether or not a parameter is required for a particular plan could be
conveyed via the relationship name instead of a literal property of the
parameter itself.
For example, the following model describes two automation plans. They use
the same parameters, but they are optional for one plan (indicated by
"hasParameter") and are required for the other (indicated by
"requiresParameter").
@prefix oslc_auto: <http://open-services.net/ns/auto#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
_:b1 a oslc_auto:AutomationParameter ;
dcterms:title "ipaddr" .
_:b2 a oslc_auto:AutomationParameter ;
dcterms:title "hostname" .
[] a oslc_auto:AutomationParameter .
<http://foo.com/automations/plan1>
a oslc_auto:AutomationPlan ;
oslc_auto:requiresParameter
_:b1 , _:b2 ;
dcterms:title "plan 1" .
<http://foo.com/automations/plan2>
a oslc_auto:AutomationPlan ;
oslc_auto:hasParameter
_:b1 , _:b2 ;
dcterms:title "plan 2" .
Best wishes,
Paul McMahan
Rational Quality Manager
From: Charles Rankin/Austin/IBM at IBMUS
To: oslc-automation at open-services.net
Date: 01/16/2012 06:35 PM
Subject: [Oslc-Automation] Definition of "parameter"
Sent by: oslc-automation-bounces at open-services.net
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