[Oslc-Automation] action metadata at resource type (shape) level

[John Arwe]

>> Also I would like to hear any comments on the choice of predicates 
>> that we have for replacing spi:instanceActions. I am not sure if 
>> oslc-automation:futureActions is the right one for this - but will 
>> like to hear back from the group. I would rather not come up with 
>> our own - if there is something already defined for the same purpose. 

> With this proposed defintion of oslc_auto;futureAction, I believe it
> would make sense within that definition to use that predicate on the
> type or resource shape to point to actions that may be available on 
> resources of that type/shape. (However, this is just my individual 
> opinion - I'd appreciate other working group members weighing in too). 

Perfectly reasonable.  Suggested it myself privately a few weeks back, 
although given the listserv SNAFU I'm not sure if that was before or after 
Anamitra's email was sent.
Even if we made no other changes in 2.1 based on his usage, this seems 
reasonable to me to add a scenario for, and legitimize the usage in the 
spec text as another known usage.  I.e. as an example, no normative 
changes required.  I don't see any value yet in adding a new 
shape-specific predicate for this purpose.

> 3) ... just to allow the mobile 
> app to list all the actions available on a given resource instance 
> and allow the user to select any of them. RDF is capable of 

My sense is that this was done for efficiency (send less content to the 
client over the "narrow" connection).  If so, it's debatable where to 
place optimizations.  Historically, the OSLC domain spec approach has been 
described to me as "what's the simplest possible way to support the 
scenarios in scope" ... simplest, not most efficient.  "Efficient" will 
vary based on the variables being optimized, and those are a function of 
"things as they are now" in most cases, rather than "laws of physics".  I 
have seen many attempts at local optimization (here, in the sense of 
"what's under my control") that turn out not to matter in the larger 
system.  For example, if there's a gzip content coding being used on these 
requests, all that "common stuff" compresses well so the "extra" on the 
wire is much less than you'd think.

What this might be getting at is a need to create bindings at run time by 
merging "what's unique to the resource" (in his case, the request URI) and 
"what's the same across many resources" (method, version, ...).  Something 
like the Plan/Request model with default parameter values on the Plan, in 
its own way.  If that's the case, one way to approach it might be:

- There is one Plan per action per shape, linked to support the 
design-time introspection.
- The HTTP version and method properties are unneeded as parameters, since 
the Automation Request interaction pattern is being used ... which, in the 
end, means that the method WILL be POST and the version is left 
unspecified by Automation (any sane implementation today would use 1.1).
- The Plan has whatever parameters it has, including zero.  Any parameters 
either have defaults, or not.... vanilla Automation 2.0.
- The server implementation always responds with the synchronous style 
from Automation, which perfectly matches a vanilla HTTP request.

The example Anamitra provided appears to have a body on his post requests 
(from the shape), which sounds like a fixed body interaction pattern 
rather than Automation Request; the mapping from fixed to AutoReq is 
pretty trivial though.

Aside from Plan/Request, another place in existing OSLC where there's a 
type/instance dichotomy is in resource shapes.  Actions 2.0 defines an 
interaction pattern that uses a shape to describe the request body, but 
here the spi:instanceAction is being used to describe the content (not 
shape) of an action binding (ow, my head).  Future actions with >0 
bindings is outside the territory we've been thinking about up to now too.

Yet another place is the "template" notion in Automation 2.1.  It's not 
too much of a stretch, once you understand Automation Request templates, 
to see what Anamitra's got in his shape as a binding template.  Just like 
creating an Auto Req from a template involves potentially modifying 
(merging) inputs (the non-scheduled case when a human is involved), 
creating a client-useful binding in Anamitra's example involves merging 
instance and shape (class) data.

> that allows you to do that - there is no explicit support in there 
> for URI templates (as used in your example). 

That line is commented out, so I'm not sure to what degree it's relevant. 
Anamitra?
I will note that URI templates are basically about name/value parameters 
in this example, which directly maps to Automation Parameters 
conceptually.

>> As you can notice - http:requestURI - which is marked in the spec as 
>> Exactly-One - would be something that we would have no need of at 
>> this "blue-print" stage. 
> 6) Also, if you were to use oslc_auto:futureAction (or follow the 
> same pattern), then your action on the reosurce shape would require a 
URI: 

Seems like feedback at 2 levels.

1: Should the spec say 1:1 or 0:1?  We did debate that before, and (memory 
vague) it came out 1:1 due to an absence of scenarios needing 0:1.  I.e. 
if we were to add a new scenario (now or in the future) that required the 
request URI to be optional, we'd change the spec to say 0:1 instead.

2: (meta) I won't be 'compliant' with Auto-2.1 and/or Actions-2.0 if I 
omit the request URI.  As the previous comment shows, the 1:1 is more 
about client expectations within the scope of *current* scenarios than 
compliance (which, as a term of art, is intentionally undefined in OSLC). 
It would be true that a client only coded to Actions 2.0's HTTP 
interaction patterns would be unable to execute an httpRequest Action 
lacking a request URI.  If the Plan-based alternative outlined above pans 
out, a client only coded to Actions 2.0's AutoReq interaction pattern 
*would* be able to execute his actions, though.

> 5) And finally, a small point: the Actions specification suggests 
> that you identify what the action does by using an rdf:type value In
> your examples you use oslc:usage. So to follow that suggestion your 

+1



Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140716/164adf88/attachment-0003.html>