The minutes [1] are now available. This discussion boiled down to the questions "Does oslc_auto:state have to be exactly-one on Automation Results? or can it be zero-or-one given we have an oslc_auto:verdict of oslc_auto:incomplete?"
The argument for making it zero-or-one was that some service providers may primarily track the lifecycle of an execution in the Request artifact rather than the Result. The specification does not currently state when Results should or must be created and leaves it to the service provider. There was a feeling that some service provider implmentations might not be able to easily carry state over to the Result. Conclusion was to update Result to make state zero-or-one and solicit opinion on the mailing list. [1] - http://open-services.net/bin/view/Main/AutomationMeetings20120614 Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170 [email protected] wrote on 06/18/2012 11:40:19 AM: > John Arwe/Poughkeepsie/IBM@IBMUS > Sent by: [email protected] > > 06/18/2012 11:40 AM > > To > > [email protected], > > cc > > Subject > > Re: [Oslc-Automation] [oslc-core] Request for review of OSLC > Automation specification > > 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_______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
