[Oslc-Automation] Bi-direction Actions/Auto spec dependencies, & action metadata at resource type (shape) level

Steve K Speicher sspeiche at us.ibm.com
Mon Sep 15 09:12:11 EDT 2014


> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 09/15/2014 08:13 AM
> Subject: Re: [Oslc-Automation] Bi-direction Actions/Auto spec 
dependencies, 
> & action metadata at resource type (shape) level
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> > Which may mean either: 
> > (1) Core does not provide a way to unambiguously determine which 
> > concrete action to use for a given future action 
> 
> s/to use for/corresponds to/ 
> 
> The linkage is _from_ the instantiated "concrete" action back to the 
future 
> action (from the specific to the generic, if you like).  The diagram in 
Auto
> 2.1 shows this more clearly than our choice of adjectives facilitates 
... 
> IIRC there was a Matt Smith Dr Who episode where the linguistic 
complexities
> of describing time travel came up in a similar fashion; if a Time Lord 
can't
> figure it out, I give up too.  Look at the diagram. 
> 
> > or 
> > (2) Core is importing part of the Automation spec (not just the 
> > vocabulary) - which may be a bi-directional dependency. 
> 
> Myself, I don't remember which bit of scenario led to the inclusion of 
the 
> _executes_ predicate in Automation. 
> I don't remember such requirement from CM 3.0's scenarios (Steve/Sam?). 

I can't see how this predicate maps to anything motivated from any of CM's 
scenarios.  Also, for what it's worth, I don't see anything wrong with 
defining it in Core and having Automation reference or the other way 
around.  Logically, the idea of future actions (which sound a little more 
like "follow up" or "post" actions) seems generic enough, and simple 
enough, it could live in Core.

Also, I read 2 predicates in the core spec as oslc-automation:futureAction 
and oslc:futureAction: are there really 2?  I think this is a typo.

Another thing, I see a mix of the usage of oslc_auto: and 
oslc-automation:, I believe it should be oslc-automation:

- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140915/12809d16/attachment-0003.html>


More information about the Oslc-Automation mailing list