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

[John Arwe]

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

No; I got tangled up myself between them.  No objection if they can (or 
do), but I have no guarantees that it's always possible. 
I *do* think however that if a client sees a single :binding with both a 
"fixed" body (e.g. :contentAsRdf) and a resource shape, that the client is 
allowed to infer by the draft rules that the provider *has* done exactly 
that, and the consumer May decide to use it.

But in the pure-resource shape case, there is nowhere existing I can think 
of where a client could infer the acceptable content types.  We could 
align with Core for the minimum base, we just need to "be careful" how we 
do that given that Core 2 requires RDF/XML and Core 3 likely requires 
Turtle (perhaps JSON-LD) as the minimum.  It would be a feechur if we 
didn't need to rewrite Actions when/if Core changed, aside from updating 
the normative reference.

> 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. 

I think something's "template-ness" is a question of how it's used, not 
what it is.  If you subscribe to the idea that creation factories should 
be able to accept something as input that allows a client to influence (in 
large part, determine) what the CF constructs - regardless of the type of 
the output - then one might conclude you feel the same way (even if only 
by implication).  The CF doesn't care (generally speaking) whether its 
input "is" an existing resource or not, or where the client obtained that 
input.  I can feed identical inputs to the same CF twice in succession and 
get different results, I can feed the same input to two different (but 
similar) CF implementations and get similar-but-different results (1 CF 
looks at 3 of the input properties, another at 4), and so on.

I don't see any way to cover cases where the client "calculates" the input 
other than having the CF advertise its media type support.  We Might deem 
the draft Accept-Post header from LDP good-enough, but (fair disclosure) 
that tells a client which media types are accepted on POST, not that the 
semantic will be create (the CF's context ... how the client finds the CF 
... might be deemed sufficient to close that gap).

> 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. 

I read it more widely; in my tiny mind, the Automation Request IP is just 
a special case of CF IP, since (all the Actions terms aside) AR builds on 
Core CFs.  I'm not sure that Actions needs to define an IP for "vanilla" 
CFs (the "superclass" IP), since no scenarios today need it *at that level 
of abstraction* ... CM and AR both incorporate it already.  If someone "in 
the future" wanted a vanilla-CF IP they could still define it without 
disturbing CM or AR ... the spec factoring might no longer be minimal, but 
that's purely a spec issue.


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/20140113/8557eb5a/attachment-0003.html>