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 [email protected] wrote on 06/13/2012 03:21:56 PM: > From: Michael F Fiedler/Durham/IBM@IBMUS > To: [email protected] > Date: 06/13/2012 03:24 PM > Subject: Re: [Oslc-Automation] [oslc-core] Request for review of > OSLC Automation specification > Sent by: [email protected] > > 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
