[Oslc-Automation] [oslc-core] Request for review of OSLC Automation specification

[John Arwe]

Not seeing minutes yet, and just getting to this email ... what was the 
result of the discussion?
My gut reaction is that state is required.  If the provider exposing the 
HTTP resource (of type AutomationRequest in this case) does not know its 
state, presumably due to some catastrophic error, I'd say then it ceases 
to be an HTTP-addressable resource... 404/410 reasonable, potentially 5xx 
at first blush.
If there's a "reasonable story" where state is not required, I'm willing 
to listen however.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario


oslc-automation-bounces at open-services.net wrote on 06/13/2012 03:21:56 PM:

> From: Michael F Fiedler/Durham/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 06/13/2012 03:24 PM
> Subject: Re: [Oslc-Automation] [oslc-core] Request for review of 
> OSLC Automation specification
> Sent by: oslc-automation-bounces at open-services.net
> 
> With respect to the state/verdict discussion in this thread.
> 
> The specification does define the states and verdicts [1].
> 
> States are:  new, queued, inProgress, canceling, canceled and 
> complete.   The intent is to indicate where the request or result is
> in its lifecycle
> Verdicts are:  incomplete, pass, warning and fail.   The intent is 
> to indicate the relative success of the execution.
> 
> On an automation result, I could see the  possibility of not making 
> state mandatory since we have the incomplete verdict.
> 
> I've queued up discussion of whether state should be mandatory on 
> results as an agenda item for tomorrow.
> 
> 
> Regards,
> Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120618/546f0788/attachment-0003.html>