[Oslc-Automation] Changes applied, specs almost ready for finalization - Re: Minor comments to OSLC Automation 2.1

Umberto Caselli umberto_caselli at it.ibm.com
Thu Nov 13 09:54:21 EST 2014


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



From:   Martin P Pain <martinpain at uk.ibm.com>
To:     oslc-automation at open-services.net
Date:   11/13/2014 11:07 AM
Subject:        [Oslc-Automation] Changes applied, specs almost ready for 
finalization - Re: Minor comments to OSLC Automation 2.1
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



Proposed solutions for points 2, 3 & 4 have now been applied to the spec: 
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/ 


Tim, could you review these changes please? 

Once we have resolved point 1, I believe we can put both Automation 2.1 
and Actions 2.0 into finalization, thanks to Tim's review of Automation 
and Ian's review of Actions. 

Thanks, 
Martin


"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 
> 
> > (2) Property "oslc:futureAction": In the description it says "..will 
become
> > available on Auto Results that execute this Plan...". Is this correct?
> > Doesn't an Auto Request execute the Auto Plan and the Auto Result only
> > represents the state (and final results) of this execution?
> 
> I propose changing "Auto Results that execute this Plan" to "Auto 
> Results that result from execution of this Plan", to make it a bit 
clearer. 
> 
> 
> > (3) "Resource: Dialog": I think this part is new in Auto 2.1, and I 
don't
> > understand why this resource is only for deferred-execution. As far as 
I
> > understood the immediate-execution should be also available via a 
dialog,
> > so why isn't this described here at this point as well or split up 
into
> > "Resource: Deferred Exec Dialog" and "Resource: Immediate Exec 
Dialog"?
> 
> That is a bit confusing, you're right. Only the last property in the
> table is specific to deferred execution dialogs - I believe the rest
> apply to all of them. 
> 
> I propose changing the introduction to that resource shape to from: 
> "A deferred-execution creation dialog describes a delegated user 
> interface (UI) which can be used to allow a user to interactively 
> create a new Automation Request that is not immediately available 
> for execution. Dialogs in general are defined by OSLC Core 2.0, and 
> re-used here." 
> 
> to say: 
> "Dialogs in general are defined by OSLC Core 2.0, and this 
> specification defines two specific types of dialogs: the _immediate-
> execution creation dialog_, which can be used to allow a user to 
> interactively create a new Automation request which is immediately 
> available for execution, and the _deferred-execution creation dialog_
> , which create a new Automation Request that is not immediately 
> available for execution, but which requires further work on the part
> of the consumer. " 
> 
> Also for the description for the "oslc:usage" property in that shape
> to be changed from: 
> "An identifier URI for the domain specified usage of this dialog, 
> for example a deferred execution creation dialog. It is likely that 
> the target resource will be an oslc_auto:DeferredExecution but that 
> is not necessarily the case" 
> 
> to say:
> "An identifier URI for the domain specified usage of this dialog. 
> For example, for a deferred execution creation dialog this will be 
> oslc_auto:DeferredExecution." 
> 
> And change this line in the table: 
> "Core 2.0 Actions-defined Properties added to Dialog by Automation" 
> 
> to say: 
> "Core 2.0 Actions-defined Properties added to Dialog by Automation -
> only used by the _deferred-execution creation dialog_." 
> 
> And also append this text to the end of the "oslc:binding" 
> property's description on that shape: 
> "This property is only used by the _deferred-execution creation 
dialog_." 
> 
> 
> > (4) Section "OSLC Actions and Automation / Discovering actions that 
will be
> > executable after an Auto Requ completes": Text says "...If the Auto 
Request
> > resulted in a new resource being created". -> Wouldn't be a "If the
> > execution of an Auto Plan through/ by and Auto Request resulted in a 
new
> > resource..."?
> 
> The terminology's a little loose here. In a sense the Request does 
> get "executed", which consists of "executing" the [automated process
> represented by the] Plan, with the parameters which were specified 
> on the Request. If we were sticking with the terminology exactly as 
> it is on the diagram, your suggestion would be right. However, for 
> the sake of fewer words, I think changing it to be "If the execution
> of the Auto Request resulted in a new resource being created" would 
suffice. 
> 
> So I propose changing "If the Auto Request resulted in a new 
> resource being created" to "If the execution of the Auto Request 
> resulted in a new resource being created". 
> 
> 
> Please +1 or suggest improvements, 
> Thanks, 
> Martin
> 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
> _______________________________________________
> 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
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) 
Cap. Soc. euro 347.256.998,80
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società con unico azionista
Società soggetta all?attività di direzione e coordinamento di 
International Business Machines Corporation

(Salvo che sia diversamente indicato sopra / Unless stated otherwise 
above)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20141113/b110cfb0/attachment-0003.html>


More information about the Oslc-Automation mailing list