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

[John Arwe]

> appropriate in 2.1 ... saying that if it returns a verdict other than 
"passed" (or perhaps "warning") that it returns a 5xx or 4xx status code? 
(I believe they all permit a response body). 

The Automation-level "problem" with doing that is that the synch execution 
style is something that the provider is permitted to select on a request 
by request basis.  Some providers are simpler today, but that's the 
general case.  What you're suggesting is certainly allowed: when the 
provider knows "early enough", here's an additional case it can optimize.

The fundamental problem though is that (in the Auto Request asynch case) 
the failure may not be known until *after* the create response has been 
sent.  So the AR IP could inherit from the FB IP *only* if the request is 
always synch-style; since not all AR flows are synch style, the AR IP 
(which encompasses both synch and asynch styles) cannot inherit from FB in 
the general case.  We could spec it such that *when the provider 
guarantees that the AR-synch style will always be used* that the provider 
can expose a binding recognized as FB whose body happens to be a AR, and 
otherwise it Must Not do so.  That's tugging at my "overly complex" meter, 
but if "hidden" inside the Automation spec where the synch/asynch 
dichotomy is already exposed it's probably ok.

> WebDAV's 424 "Method Failure" [1] [2] might be appropriate. 
> (This would mean that those implementations that use 2.0 synchronous 
execution would not be compliant to 2.1 - so this might be more 
appropriate for 3.0 than 2.1). 

"Method failure" is a string I only see in the MSFT doc; all the normative 
references like RFC4918 say "Failed Dependency".  Reading the RFC's 
section on 424 and PROPFIND, it wouldn't be my first (or fourteenth) 
choice.

> Or do you think it would be more appropriate to split the FB and AR 
interaction patterns? 

I convinced myself above (...*only* if...) that they must be split; 
they're just incompatible (wrt how the client detects failures) in the 
asynch execution style.

> Any individual provider would still be free, I believe, to use a 4xx/5xx 
return code in the synchronous AR case, as in the paragraph above, and so 
use an AR as a fixed body, but it would have to explicitly make it 
recognizable as both, rather than the spec doing so. 

Agree

> I guess we can always suggest it, or even make it a best practice, to 
support FB when using AR (which should work fine with asynchronous 
execution, and the change above can make it work with synchronous 
execution). 

So far, n-1 of the 5ish implementations I have using or planning to use 
Automation are in the "my requests are 'always' long-running, I'll always 
use the asynch style, and keep things consistent for clients" camp.  The 
other is, so far I think, the polar opposite (always synch; I just don't 
know how long that will actually fly for them).  Offering multiple 
bindings, one FB and one AR, is something I see only when we have multiple 
products able to manage a single resource (which they each represent 
independently, and then we have to link together later in 'third party' 
code)... the "link them together" code might well merge actions if the 
types are compatible.  Maybe other cases will emerge over time, but I 
don't see *any* current implementations saying that it's a best practice 
to offer both.

> The only question for that approach is what is the recognition rule for 
AR? 

Just remove the oslc:ContentFromRepresentation resource , so it works like 
resource shape? 
oslc:binding [
        a       http:Request
        http:body       [
                a       oslc-automation:AutomationRequest
                ...
        ]
]


> I feel like we should go with splitting the patterns, 

agree

> and documenting in what cases you can use them together 

I'm closer to 'on the fence' about this.  If it's "true but not commonly 
used" consequence of the spec, I'd be tempted to relegate it to a 
companion document.  We considered doing that for synch/asynch "styles" in 
2.0 but ran out of energy.

> (I probably can't make a convincing enough argument for making it a best 
practice - we can discuss whether any profile should require both from 
providers), 

my views above.

> then propose for 3.0 that synchronous execution returns a non-2xx code 
for failure. 

This seems like an option (consequence of the current spec), so I wonder 
if it belongs in a companion document.... perhaps along with the whole 
synch execution style.


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/20140314/bca7ac49/attachment-0003.html>