> From: John Arwe/Poughkeepsie/IBM@IBMUS > To: oslc-automation@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-boun...@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
