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

[Martin P Pain]

> From: John Arwe <johnarwe at us.ibm.com>
> ...
> Q1: in the resource shape interaction pattern, we say that the 
> client serializes the RDF in an "appropriate" format.  I don't think
> it gives the client any way to find out what constitutes 
> "appropriate" though.  My thinking was that we say the provider has 
> to offer a representation (including the binding data) using a 
> format it supports for input; we'd either use the existing header 
> mechanisms to assert its content type, or invent new if necessary. 
> I.e. a client happy to take the defaults could just "copy" the 
> contents of :contentAsRdf, copy the Content type header, done.  I'm 
> only concerned with that minimum sort of baseline; if the provider 
> accepts others and the client wants to introspect at run time, all 
> the HTTP substrate can be used.  "with RDF body" has some words 
> around this that could be re-used, and/or re-factored into the appendix. 


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, but in the Actions spec 
might make more sense now). That can then contain the information about 
how to serialize.

That definition of the term "template" can then say "use the Content-Type, 
etc, that the template was served with", and "in the basic case the 
consumer submits the template exactly as it received it, but if the 
consumer want to introspect and make changes at runtime, all the HTTP 
substrate can be used".

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". If so, would that mean ALL "with resource shape" bindings 
would be valid "with RDF body/with template" bindings? Or did I 
misunderstand you when you said "could just "copy" the contents of 
:contentAsRdf"? (I expect you were just saying "only server up the 
bindings in a format that you accept as input", but what you said later in 
that paragraph formed this idea).


> Q2: [having read Only the Core piece so far] it was moderately 
> surprising to see the Creation Factory IP point off to Automation; 
> CF's are part of Core, that sort of thinking.  Core-Actions for CFs 
> and Automation-=Actions for templates is what I expected coming in. 

In my mind the Creation Factory IP is only really useful as a "secondary 
binding"/"immediate execution binding [in the context of a template 
dialog]". Although I suppose it's possible that it too points to a 
resource shape, which perhaps makes it equally as useful as the resource 
shape IP, which means it could be in Actions. 

(And this also raises the question - should we just replace the "with 
resource shape" IP with the CF IP? That would leave "template body" {with 
"empty body" and "Automation Request template" as special cases of 
"template body"}, which would provide one way of simplifying the "HTTP 
request" IPs down to a single IP.)

> I'll come back to the "do we need
> that level of indirection" question later today.  I think that's the
> only big-animal one open (jog my memory if there are others)

For dialog execution, I think the only other big thing remaining is the 
Automation case of configuring an action for a context-resource that does 
not yet exist (which I have an idea for).
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 answer, 
although there are many small ones.
(The "indirection" question is issue 11, but also is strongly related to 
issue 3).

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/20140113/4f330ee7/attachment-0003.html>