[Oslc-Automation] [v2.1] Re: executionEnvironment input parameter (final change to OSLC Automation 2.1)
Martin P Pain
martinpain at uk.ibm.com
Wed Jan 28 13:34:08 EST 2015
I hate to bring up more questions after we stopped talking about this
months ago (and my apologies for not putting this into the spec when we
talked about it), but there is a very quick question about how we put this
proposed change into the spec.
I very much like Tim's suggested approach:
> "If more than one execution environment is specified on the Automation
> Plan, the consumer has to specify the desired execution environment
> as part of the Automation Request, he is constructing for the Automation
> Plan's execution. The execution environment is provided as
InputParameter
> to the Automation Request.
>
> The consumer is expected to find a parameter definition from the
> Automation
> Plan with its oslc:propertyDefinition property set to
> http://open-services.net/ns/auto#executionEnvironment, and create an
> InputParameter on the Automation Request for that parameter definition,
> specifying the execution environment to use (choosing out of those
> specified on the Automation Plan). If that parameter definition's
> oslc:occurs property is exactly-one or one-or-more, then the consumer
MUST
> specify an execution environment, Otherwise, the consumer MAY specify an
> execution environment."
However, that is too much text for the "description" cell in the resource
shape table:
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#AutomationPlan-Properties
If we are going to put that text in, I believe we will need a new section
for it, probably called "execution environments".
Options are:
1. A new section under "Automation Service Provider Capabilities" [1]
2. A new section under "Automation Specification Guidance " [2] (the
benefit of this is that it's non-normative, so it's less of a change)
3. A new sub-section under "Automation Resource Definitions " -> "
Resource: AutomationPlan " [3] below the resource shape table. (Benefit:
it's close by to the existing reference to the execution environment
predicate. Downside: nothing else does that.)
I'm going to have to propose that we take approach #1, to be consistent
with other capabilities, and insert a new "Execution environments" section
(after the "Delegated Uis" section) with the text:
An AutomationPlan can use the `oslc_auto:usesExecutionEnvironment`
predicate to link to a resource representing the environment(s) which that
Automation Plan can be executed in. The execution environment resource
could represent a grouping of environmental details such as operating
system, database, browser, compiler, etc. The type of that resource, and
the predicates to use on it, are not defined by this specification.
> "If more than one execution environment is specified on the Automation
> Plan, the consumer has to specify the desired execution environment
> as part of the Automation Request, he is constructing for the Automation
> Plan's execution. The execution environment is provided as
InputParameter
> to the Automation Request.
>
> The consumer is expected to find a parameter definition from the
> Automation
> Plan with its oslc:propertyDefinition property set to
> http://open-services.net/ns/auto#executionEnvironment, and create an
> InputParameter on the Automation Request for that parameter definition,
> specifying the execution environment to use (choosing out of those
> specified on the Automation Plan). If that parameter definition's
> oslc:occurs property is exactly-one or one-or-more, then the consumer
MUST
> specify an execution environment, Otherwise, the consumer MAY specify an
> execution environment."
And then including a "See also the [execution environments] section" in
the predicate's description cell.
Tim (or anyone else still monitoring this list) please could you +1 or
provide feedback? Thanks.
[1]
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Automation-Service-Provider-Capabilities
[2]
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Automation-Specification-Guidance
[3]
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Resource_AutomationPlan
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
18/11/2014 16:40:49:
> From: Tim Friessinger <TFRIESS at de.ibm.com>
> To: oslc-automation at open-services.net
> Date: 18/11/2014 16:41
> Subject: Re: [Oslc-Automation] Oslc-Automation Digest, Vol 45, Issue 2
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
>
> Hello,
>
> I'd also prefer (2), because (3) is to much "open world" in my opinion
and
> (1) is not as I would expect for OSLC.
> About the wording: I would start with a (informal) text, before going
into
> the details, to help a reader to easily grasp the basic idea,
> before he's confronted with the technical details. E.g.:
>
> "If more than one execution environment is specified on the Automation
> Plan, the consumer has to specify the desired execution environment
> as part of the Automation Request, he is constructing for the Automation
> Plan's execution. The execution environment is provided as
InputParameter
> to the Automation Request."
>
> Now the more formal explanation can follow:
> "The consumer is expected to find a parameter definition from the
> Automation
> Plan with its oslc:propertyDefinition property set to
> http://open-services.net/ns/auto#executionEnvironment, and create an
> InputParameter on the Automation Request for that parameter definition,
> specifying the execution environment to use (choosing out of those
> specified on the Automation Plan). If that parameter definition's
> oslc:occurs property is exactly-one or one-or-more, then the consumer
MUST
> specify an execution environment, Otherwise, the consumer MAY specify an
> execution environment."
>
>
> Mit freundlichen Grüßen / Kind regards
>
> Tim Friessinger
>
> System Automation for z/OS Development
> IBM Software Group, Tivoli
> IBM Lab Boeblingen, Germany
>
>
>
>
>
> Phone: 49-7031-16-2535 IBM Deutschland
(Embedded
>
> image moved
> to
file:
>
> pic06847.gif)
>
> E-Mail: tfriess at de.ibm.com Schoenaicher Str.
> 220
>
> 71032 Boeblingen
>
> Germany
>
>
>
>
>
> IBM Deutschland
> Research &
> Development
> GmbH /
> Vorsitzende des
> Aufsichtsrats:
> Martina Koederitz
> Geschäftsführung:
> Dirk Wittkopp
> Sitz der
> Gesellschaft:
> Böblingen /
> Registergericht:
> Amtsgericht
> Stuttgart, HRB
> 243294
>
>
>
>
>
>
> oslc-automation-r
> equest at open-servi
> ces.net To
> Sent by: oslc-automation at open-services.net
> "Oslc-Automation" cc
> <oslc-automation-
> bounces at open-serv Subject
> ices.net> Oslc-Automation Digest, Vol 45,
> Issue 2
>
> 11/13/2014 06:00
> PM
>
>
> Please respond to
> oslc-automation at o
> pen-services.net
>
>
>
>
>
>
> Send Oslc-Automation mailing list submissions to
> oslc-automation at open-services.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
> or, via email, send a message with subject or body 'help' to
> oslc-automation-request at open-services.net
>
> You can reach the person managing the list at
> oslc-automation-owner at open-services.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oslc-Automation digest..."
>
>
> Today's Topics:
>
> 1. executionEnvironment input parameter (was: Changes applied,
> specs almost ready for finalization - Re: Minor comments to OSLC
> Automation 2.1) (Martin P Pain)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Nov 2014 15:49:31 +0000
> From: Martin P Pain <martinpain at uk.ibm.com>
> To: Umberto Caselli <umberto_caselli at it.ibm.com>
> Cc: oslc-automation at open-services.net, Tim Friessinger
> <TFRIESS at de.ibm.com>
> Subject: [Oslc-Automation] executionEnvironment input parameter (was:
> Changes applied, specs almost ready for finalization - Re:
> Minor
> comments to OSLC Automation 2.1)
> Message-ID:
>
> <OF1F39541E.38C768AF-ON80257D8F.0053D4F6-80257D8F.0056EF72 at uk.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> We need to decide how to word this.
>
> I see two or three options:
>
> 1. We don't actually use
> oslc_auto:inputParameter/oslc_auto:ParameterInstance, we just add to the
> spec to say: include an oslc_auto:executionEnvironment property on the
> Request which specifies which execution environment to use (out of the
> ones on the Plan).
>
> 2. (Background - In the spec as it stands: on the AutomationPlan, the
> oslc_auto:parameterDefinition property points to an oslc:Property
> resource. This resource has a property called oslc:propertyDefinition
> whose description is "URI of the property whose usage is being
> described".) So we could add to the spec to say:
> "If more than one execution environment is specified on the Automation
> Plan, then when the consumer is constructing an Automation Request, the
> consumer is expected to find a parameter definition from the Automation
> Plan with its oslc:propertyDefinition property set to
> http://open-services.net/ns/auto#executionEnvironment, and create an
> InputParameter on the Automation Request for that parameter definition,
> specifying the execution environment to use (choosing out of those
> specified on the Automation Plan). If that parameter definition's
> oslc:occurs property is exactly-one or one-or-more, then the consumer
MUST
> specify an execution environment, Otherwise, the consumer MAY specify an
> execution environment."
> (I'm not happy with the wording, so if you agree with this option please
> help me with the wording.)
>
> 3. Allow consumers to do either. If providers support choosing execution
> environments require them to allow consumers to use either method. If
> providers require consumers to specify their execution environments then
> they must expose a parameter definition on the plan with an oslc:occurs
of
> exactly-one or one-or-more.
>
> Option 1 seems more in-keeping with RDF.
> Option 2 seems more in-keeping with OSLC Automation as it stands.
> Option 3 seems more "open world" (to misuse the term), but I expect it
> will be harder to write up and harder to encourage compatibility between
> implementations.
>
> I suggest we do NOT do option 3.
> My suggestion is option 2, but was anyone expecting it to be option 1?
>
> Umberto, Tim & Steve, would you all be able to provide your opinion on
> this please?
>
> Thanks,
> Martin
>
>
> Umberto Caselli <umberto_caselli at it.ibm.com> wrote on 13/11/2014
14:54:21:
>
> > From: Umberto Caselli <umberto_caselli at it.ibm.com>
> > To: Martin P Pain/UK/IBM at IBMGB
> > Cc: oslc-automation at open-services.net
> > Date: 13/11/2014 14:54
> > Subject: Re: [Oslc-Automation] Changes applied, specs almost ready
> > for finalization - Re: Minor comments to OSLC Automation 2.1
> >
> > Hello,
> >
> > Regarding point 1, I agree the execution environment has to be
> > specified as an InputParameter.
> >
> > Regarding point 2, I agree with the proposed rephrasing (and you
> > already made the change, which is good).
> >
> > Thanks, Umberto
> > ----------------------------------------
> > Umberto Caselli
> > IBM Tivoli Workload Automation Development
> > email: umberto_caselli at it.ibm.com
> > phone: ++ 39.06.5966.4427
> > Via Sciangai 53 - 00144 Roma
> > ----------------------------------------
> > Nihil est agricultura melius, nihil uberius
> > nihil dulcius, nihil homini libero dignius
> >
> >
> ...
> >
> >
> > "Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote
> > on 23/10/2014 09:46:05:
> >
> > > From: Martin P Pain/UK/IBM at IBMGB
> > > To: oslc-automation at open-services.net
> > > Date: 23/10/2014 09:46
> > > Subject: Re: [Oslc-Automation] Minor comments to OSLC Automation 2.1
> > > Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
>
> > >
> > > My responses/proposals are below. Where I have proposed changes (2,
> > > 3 & 4) could any workgroup members +1 them or suggest improvements.
> > > If no objections or improvements have been heard within a week, I'll
> > > consider them approved.
> > >
> > > > (1) Property "oslc_auto:usesExecutionEnvironment": Assuming an
> > Auto Plan as
> > > > more than one execution environments. If such a plan is executed
(->
> Auto
> > > > Request), how will the Service Provider know in which environment
> the Auto
> > > > Plan should be executed? I assume
> > > > one solution is to specify this as an InputParameter, but maybe
> > it would be
> > > > good to mention this in this properties description?
> > >
> > > I think Umberto will have to respond to this one
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://open-services.net/pipermail/oslc-automation_open-
> services.net/attachments/20141113/332a17ad/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
>
>
> ------------------------------
>
> End of Oslc-Automation Digest, Vol 45, Issue 2
> **********************************************
>
> [attachment "pic06847.gif" deleted by Martin P Pain/UK/IBM]
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20150128/b3f7d220/attachment-0001.html>
More information about the Oslc-Automation
mailing list