[Oslc-Automation] OSLC Actions: Dialog for later execution interaction pattern - moved to Automation

[John Arwe]

> My current thinking is that I want to change "with RDF body" to be 
> "with template" (or "providing template"), and define the concept of
> a "template" more fully (possibly in Automation, ...

My only concern with this is having two different uses of template - this 
proposed one, and the whole "template creation dialog" topic in 
Automation.  If we're all buying the "template-ness is a function of 
usage, not being" narrative, then we should rename what's in automation 
2.1 now.  "Deferred execution" (vs "immediate execution" for the 2.0 
cases) is one idea I've had along those lines.

I do think that Action bindings' intended use of any http:body *is* a 
template usage.

> Am I right in inferring that you suggest that the "with resource 
> shape" pattern bindings should provide default body contents? i.e. a
> default "template". 

I suggest that server implementations will be driven to; at least "kind" 
ones, in the "be kind to your clients" sense.  I did not intend that the 
spec would require this.  Same as the current status quo for resource 
shapes on creation factories: keep the minimum entry point as small as 
possible.

> Or did I misunderstand you when you said "could just "copy" the 
> contents of :contentAsRdf"? (I expect you were just saying "only 

I'm not sure that my ideas then (before I had worked through that whole 
"extra" level of indirection detour I took) were completely coherent. 
There were some cases where I was making assumptions that were not true in 
all cases.

We do need some story about how a client knows what content-type(s) it can 
use when it's sending input along on http requests that allow message 
bodies.  There may be two stories, one for "arms length" cases (client 
treats body as completely opaque, sourced from a binding) and one for 
cases where the client constructs the input itself, in whole or part.  The 
latter might be as simple as: use HTTP substrate mechanisms, for example 
Accept-Post... and if we find those underspecified for our tastes, work on 
fixing it at the right (http) level instead of band-aiding it in our tiny 
application-specific layer on top of http.

> In my mind the Creation Factory IP is only really useful as a 
> "secondary binding"/"immediate execution binding [in the context of 

This might turn on the contextual meaning of CF IP, and how one recognizes 
it.  We know CM's desired result (naked post to Action resource URI, 
perhaps with a message body) makes it look a lot like a creation request, 
so I might have been thinking of that as a CF.  IIRC however their desired 
normal response is 200 not 201, which seems to rule out the C in CF.  If 
the CF IP also requires an oslc:CF resource, that's never shown up in CM's 
desired result.  So maybe again my thinking got muddied.  When I get 
confused, I don't go half-in ;-)

> Outside of dialogs, there's the question of one or many HTTP request
> IPs (Issue 16), I think that's the only big questions still to 

I think I don't care about that exact question (yesterday's responses). If 
there are fundamentally say 5 different "variations" a client might need 
to understand, whether that ends up being 5 IPs or 2 IPs with 2 and 3 
variations respectively, don't think I care much.  The client still has 5 
things to worry about either way.  If you prefer: I care about how many 
pieces of fruit there are, not whether they're apples or oranges or how 
many of each subset I have.  The fact that some are citrus and some not, 
may or may not turn out to be interesting.


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/20140116/81b08eef/attachment-0003.html>