[Oslc-Automation] Changes I have made to Actions specs based on Actions issues list

[John Arwe]

ISSUE-12: Arwe did some slight rewording in the two comment sites.
Comment: 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#executing-actions 
 
the parenthetical sentence is now a clause after the semicolon.
split the paragraph so the resource concerns are separate from the 
clients'.

moved unrelated "resources can be hash/less or blank" higher up, under 
Action Resources, where it was partially dup'd already.

Cardinality: 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Resource-Action 


Comment: 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#property-oslc-action 

Merged the paragraph Martin had updated into the predicate desc column, so 
it has a more natural home after it moves to Common Properties.


ISSUE-14: Arwe reviewed, seemed fine.


ISSUE-17: Arwe reviewed second comment, attempted to untangle it some (I 
had trouble resolving this/that/... references), thinks he found a bug 
(below) as a result.  Took a quick look at first comment; once we settle 
on the bug (is it a bug or not) we might want to propagate some subset of 
what I did on the 2nd comment; 1 is already more concrete (so much less 
tangled), just a question of how beautiful a sheen the nose cone has.

Comment 1: 
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Creation-Factory-interaction-pattern 

Comment 2: 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Interaction-patterns 




Bug(?) unearthed on -17 review: the AutoRequest IP[1] says that it extends 
the fixed-body IP.  So as I was reading -17 comment 2, trying to Really 
Clarify why this was a problem for clients, I came to a contradiction: if 
AR really is a (valid) extension of FB, then a client *should* be able to 
use either (treat AR as if it were FB).  Yet I know in practice that fails 
- not on the send side, but on the "how to interpret the response" side. A 
FB-200 means "I did it" (past tense, otherwise it should be a 202).  A 
AR-200 means "I created the AR, now you [consumer] monitor it until 
state/verdict say it's baked".  I think Martin you thought about the 
inheritance of IPs purely from the send side, without considering "what 
does 200 mean"; at least that's my best attempt to make sense of the 
currently drafted content.  I think the interaction pattern (execution 
sections, probably) need to include how the response is interpreted (ptr 
to HTTP for most, Automation for others).  I suspect that drives a change 
to the syntax - if AR is not an extension of FB, then the recognition rule 
has to change.

It should still be *possible* to use an AR as the payload of a FB IP, but 
in that case the provider can only do that if it *guarantees* that it uses 
the FB IP (meaning it Must Not return 2xx if the verdict/state is anything 
other than success).  I think Automation 2.0 would still allow that; it's 
kind of a corner case since anything other than 201 or "the create AR 
itself failed" is off the mainline path.  An Automation 2.0 provider would 
simply expose AR-only bindings, or (if it meets the tighter criteria) it 
could expose the same actions via equivalent FB bindings (whose body just 
happens to be an AR, but that's transparent to the client).



[1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-autoreq


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/20140312/6857d6ab/attachment-0003.html>