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

[Michael F Fiedler]

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
fiedler at us.ibm.com
919-254-4170

oslc-automation-bounces at open-services.net wrote on 06/18/2012 11:40:19 AM:

> John Arwe/Poughkeepsie/IBM at IBMUS
> Sent by: oslc-automation-bounces at open-services.net
>
> 06/18/2012 11:40 AM
>
> To
>
> oslc-automation at open-services.net,
>
> 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
>
>
> 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_______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120618/920ad892/attachment-0003.html>