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

[Martin P Pain]

> The linkage is _from_ the instantiated "concrete" action back to the
> future action (from the specific to the generic, if you like).
> ...
> Look at the diagram. 

Yes, you're right the linkage is in that way, because of both the timing 
of which one exists first, but also because there may be many concrete 
actions pointing to one futureAction, so we point from the many to the 
one.

> > 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. 

The link in this example on the Automation teardown scenario:
http://open-services.net/wiki/automation/Temporary-deployment-scenarios/#teardown-execution
"The consumer finds the action on the Automation Result that has 
oslc_auto:executes <plans/1/future-stop> set. It knows this is the 
executable action for this specific Automation Result that will execute 
the generic future action that the user selected and configured earlier 
(as this is the definition of oslc_auto:executes on an oslc:Action in the 
Automation specification 2.1)."

> If this is an Automation-only thing so far, it would be simple 
> enough to add a sentence to Core.
> ...
> If we determine that this is a Core requirement, it would be simple 
> enough to logically move in into Core from Automation ... meaning 
> re-use the :executes vocabulary term, and define its usage in Core 
> Actions minus the part about "the Plan" (let Automation add that 
> onto what Core defines).

I'd suggest that it is important, as it is required for any case where the 
configuration/selection of the action and its execution happen at 
different times (or multiple, repeated executions for one 
selection/configuration phase). As is the case both in my teardown 
scenario and in Anamitra's 'metadata on shapes at design-time' scneario.

So I suggest that it is needed in core - although as it stands core 
implementors can still find it if they need it.

If we move the text describing it into core, then this is looking 
increasingly like we should move the futureAction predicate into the Core 
namespace (as its entire definition will be based in a core spec), as long 
as that doesn't mess up the one implementation we are currently aware of. 
(While I'm hesitant to make too many material changes at this stage, this 
is the one place that feels the most messy that could be most easily 
cleaned up.)

> I don't think Auto 2.1 actually cares that
> the :futureAction predicate uses an AutoPlan as the subject - it 
> just happens to be true that the subject will always be of-type 
> AutoPlan because _in the context of the Automation spec_ that's the 
> only case of interest. 

It matters for only one thing: the fact that the concrete action will be 
linked to from a Result that reports on that Plan. Other uses of 
futureAction will have the concrete actions in other places. (This means 
that the one use of this predicate that we should avoid is for actions 
that will be available in future on the subject resource as then there 
will be an ambiguity when the predicate appears on Plans.)

> If Auto 2.1 does care about getting to the 
> Plan from the future Action without actually executing the action at
> least once, it's missing a link. 

I don't care about navigating in that direction.


So, to sum up - I think the facility to navigate from concrete actions to 
future actions (well, to query a set of concrete actions [on a given 
resource] to find the one that links to a given future action that was 
previously selected) is needed to Core implementations. So we should 
probably move the text there (and make it ambiguous as to the type of 
resources the actions are on, as you said).

But this is very much feeling like future action's "home" should be in 
core, and Automation re-uses it (which would mean all references Core has 
to Automation defining futureActions (or "other predicates") would need 
removing, which might not be a bad thing.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140915/7a1ebc25/attachment-0001.html>