[Oslc-Automation] OSLC Actions: URI to identify interaction patterns. Plus "templates" replacing "with RDF body" pattern

[John Arwe]

wrt the draft

I wonder if Availability scenarios would motivate the "raw" creation 
factory binding.  Maybe Juergen/Tim can weigh in.  I think they Can use 
Automation for what they've discussed, but maybe a raw CF would be cleaner 
for some pieces (e.g. if some of their interactions are just always synch, 
and we think that is likely true for "all" reasonable implementations).

You have changed (in the odt strawman) Auto Request from an IP to a 
request body type.  But Automation requires a client to understand a 
larger pattern of requests (and the Automation vocabulary) - the meaning 
of 200 is *different* for a CM-style POST (action completed successfully) 
than an Automation-style POST (action completed, look at oslc_auto:verdict 
for success/failure).  I don't think you can avoid making that a separate 
IP (at least I cannot see how).


> (1) having a single URI to identify each interaction pattern
>     (which means only having a single HTTP request pattern,
>     identifying the different ways of building content separately)

With my client hat on, I don't see what this saves me.  I don't think it 
hurts me either, FWIW.  Either factoring should work.

I think in terms of implementation effort.  Moving from dead-simple 
(relatively speaking) to maybe-harder-than-I-want-now  is:
1: a single naked HTTP request - no request body, no special headers to 
fuss with, blocking request.
2: #1 plus a fixed request body ... something I never crack open, I just 
bitwise-copy from the binding.  so the delta is I have to fish out the 
content type header :-( from the binding
3: #2 plus I crack open (parse) the body, but I never modify it, just 
serialize it (maybe with a different media type than the binding had) ... 
may drag Accept header-style info, unless we say introspect at run time 
which is fine.
4: #2 or #3 in a multi-request pattern, like Automation requests where I 
have to create something, then monitor/poll until it reaches 
&some-final-state
5: #2 or #4 where I modify the body, or construct it from scratch

Having one IP URI that covers several of those cases is functionally no 
different than saying "look for X and then Y".  I have to do that in the 
end either way.
It's like saying "you have rdfs:Resource, why do you need any other 
types?"  Because rdfs:Resource is not always the granularity that a 
client/app is interested in.  It's fine for some purposes, not others.

There are a couple of degrees of freedom involved, in branches:
- body or not (branch: if body, how to construct it)
- single request or not (more generally: which request pattern do I need 
to understand?  single, Automation, ...)

With my RESTy-spec hat on, I react in ways like "an OSLC creation factory 
isn't a HTTP request?  really?"  Yes, I can get past those, it's another 
forest/trees problem.  I won't be the only one asking though, as you go 
through multiple reviews - assuming anyone reads them.

With my OSLC-spec hat on, I see places in this that would make 
Core-Actions depend normatively on Automation (a domain spec), and Core 
has said it wants to keep all dependencies ON core FROM domains, not the 
reverse, less we end up in Dependency Hell.  I'm talking about cases like 
"Request body type: Resource template" line 476 ... whatever's needed 
should be in Core.  I'm not worried about cases where Core is just listing 
and pointing at IPs/profiles known to exist elsewhere (it's not a 
normative dependency), like line 552.

> (2) re-using the idea of "templates" from automation for the "with
>     RDF body" case, to avoid solving the same problems (e.g.
>     content-type) twice.

Conceptually, Automation's templates may be defined with some extra 
restrictions, but the general idea sure is obviously valid once you adjust 
the level of abstraction to the context.  If the other emails have led 
"you" to buy the "template is a role a resource can play" language, I'd 
certainly go there over keeping template as some kind of "thing-ness". How 
vs what.


> (3) Also, it brings the "creation factory" interaction pattern
>     into Core, but John has now suggested we only define the

If defining it in Core makes it easier for Automation to define it's 
version via layering, that could be cause to do it (I think emails earlier 
today may have helped to clarify that).  Aside from giving it a 
Interaction Pattern name, I don't think it adds any new requirements.

Maybe it should, though.  Maybe *if* you want to use a CF as an action 
binding, *then* it Must advertise resource shape(s) it accepts.  We are 
allowed to add requirements for action bindings beyond those Core-2 
defines for service providers.  Such an action binding Might still be 
incomplete/abstract: since it doesn't tell a client what type(s) are 
created, as written it seems like it could be used either for immediate 
execution or something else (like Automation requests).  Given that those 
are entirely different interaction patterns, I have a little bit harder 
time seeing the value *if* it is considered fully specified as-is.




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/20140114/963fc873/attachment-0003.html>