[Oslc-Automation] Advertising actions on the Result from the Plan

[John Arwe]

Looking at 
http://open-services.net/wiki/automation/Exposing-arbitrary-actions-on-RDF-resources/#Advertising-actions-on-the-Result-from-the-Plan 
, some comments.

Without the parameterised plan: 

- there's not enough here for a client to know it is capable of knowing 
how to invoke the future Action.  Automation would have to add that 
requirement; i.e. that the action on the result MUST at least support the 
Automation Plan implementation type, using the current terms.  If we do 
so, not much practical difference between these two options that I can 
see.

- the Result might offer multiple Actions, with duplicate rdf:type sets, 
some supporting the Automation Plan implementation type and others not 
supporting it.  I'm allowing, for example, that the Plan and Result are 
owned by different providers, which is a case I remember at least one 
implementation saying they had; the Result provider could offer a stop 
action (that the Plan provider somehow knows about - how, I don't care) 
and a second stop action implemented by a third provider.  This seems like 
a stretch, but if the Result provider allows updates (put/patch) that add 
actions, there you are.  We don't have to solve that, but if there's an 
option that clearly does/not it would be useful to keep in mind.


With the parameterised plan: 

- the "orchestration composition time" problem I think is that the 
requestURI value is unknown on the Plan.  Reusing core:Action with 
requestURI 0:1 (or 0:0) seems right to solve that.

- dcterms:identifier is only going to be useful if both Plan-Action and 
Result-Action are somehow known to come from the same Provider, which 
Automation does not guarantee (tolerable) but also does not give the 
client any iron-clad always-available way to know (less attractive - I 
don't think we Require oslc:serviceProvider links).  It really wants to be 
a URI, but it seems likely that (ala requestURI) the correct URI (to the 
Result-Action of interest, which is inherently scoped to 1 request) cannot 
be reliably known from the Plan (which is scoped to 0:n Results).  In 
cases where the resource context is supplied outside the request URI (e.g. 
in a fixed body), I can see a URI working.

- I don't see any way to link them reliably in the case where Plan and 
Result come from different providers, using current Automation means.  I 
think we also had implementation cases where the Request and Result came 
from different providers (potentially separated by queueing and 
delegation), which Does Not Help at all.


"without" + adding the MUST support AP implementation type seems like the 
minimum that Could work, so I'm tempted to start there and say any 
improvements in robustness/reliability are implementation extensions. 
Which is vaguely unsatisfying.

I wonder out loud: if the Result-Actions (as in the "with" option, fully 
fleshed out with the final requestURI) were linked via actionOnResult from 
the Request, would that satisfy the scenario?  The scoping problem is 
solved there at least.  Not all implementations would necessarily have the 
information available that early, but for those that do the consumer could 
build the full stop request "immediately" upon receipt of a representation 
of the Automation Request if it so desired.  Implementations wishing to 
have fully reliable matching could also assign a proper URI (possibly hash 
URI) to the Action, once there is a Request with matching scope... given 
that, consumers would have zero doubt that they got the intended Action. 
Once blank nodes are allowed as Actions, there is just no reliable way to 
match, best anyone could do is duck-typing it.

(Wild thought, again requiring that a single provider own the Plan and 
Results) we could also say that the requestURI on the Plan is a URI 
*template* (RFC 6570), which through some Jedi mind trick we know how to 
resolve fully (perhaps using the final request parameters... inputs + 
outputs... as input name/value pairs to resolve the template).  This 
quickly gets too complex again.

Net: I do see how some particular implementations could accomplish this. I 
do not see how it can be done using Automation alone by *all* the 
implementations I remember us discussing in the past as being either 
permissible or real.  Simply too many degrees of freedom in the general 
case.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131016/b8b53ab0/attachment-0003.html>