[Oslc-Automation] Preparing OSLC Automation specification for finalization

[Michael F Fiedler]

This was discussed in a couple of the  workgroup meetings.   The decision
was that state is required since there are known instances of providers
which do not persist Requests.  But, there is nothing which says the state
in the Result has to track the lifecycle of the execution.   A Result can
be created with a state of "complete" and a final verdict if the Result is
only created when the verdict is known.   Or a state can be created with a
value of "inProgress" and then moved to "complete" once the verdict is
known.  There are no required state transitions in the specification.

Can you give details on an implementation challenge here if it is
acceptable to create the Result with a state of "complete"?  or having it
be "inProgress" initially and then moved to "complete"?


Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170

Pramod K Chandoria <pchandor at in.ibm.com> wrote on 08/16/2012 06:56:19 AM:

> Pramod K Chandoria <pchandor at in.ibm.com>
> 08/16/2012 06:56 AM
>
> To
>
> Michael F Fiedler/Durham/IBM at IBMUS,
>
> cc
>
> oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
>
> Subject
>
> Re: [Oslc-Automation] Preparing OSLC Automation specification for
finalization
>
> Hi Mike,
> On of the thing which causes adoption issues in Rational Quality
> Manager is the mandatory 'state' attribute on Automation Result
> (besides mandatory verdict) which is actually 'spill over' from
> Automation Request.
> Probably it must be optional so service provider can get it's value
> from Automation Request as long Automation Request has not been
> purged. Service providers should not be forced to introduce state of
Result.
> The service providers which truly supports complete lifecycle of
> Automation Specification resources  Automation Plan -> Automation
> Request -> Automation Result, will face this issue.
> I know this issues has been raised earlier as well but worth to
> mention as implementation challenge for RQM down the line.
> Any thoughts?
>
> Regards
> -|- Pramod Chandoria
>
>
>
> From:        Michael F Fiedler <fiedler at us.ibm.com>
> To:        oslc-automation at open-services.net
> Date:        08/15/2012 06:46 PM
> Subject:        [Oslc-Automation] Preparing OSLC Automation
> specification for        finalization
> Sent by:        oslc-automation-bounces at open-services.net
>
>
>
> The OSLC Automation workgroup has wrapped up all open issues raised
> so far and it is time to think about moving the specification to
> Finalization phase.   Finalization means that the specification is
> ready for implementation and can still be updated based on
> implementation experience.
>
> Some items in the spec that are not yet complete or in need of update
are:
>
> Appendix A (Samples):  Update to be in alignment with the spec
> Appendix B (Resource Shapes):  Need to be created
> Automation Vocabulary (http://open-services.net/bin/view/Main/
> AutomationVocabulary) : reviewed and updated as needed
>
> I will start working on these items for next week's (23 August)
> workgroup meeting.  If anyone wants to assist, let me know.
>
> Additional activities that will start soon and carry into
> Finalization are:  Automation reference implementation and
> Automation test suite.  I have proposed these assets be created in
> the Eclipse Lyo (http://eclipse.org/lyo) project.   Some folks have
> expressed interest in participating in these activities in the last
> workgroup meeting.  If you would like to add your name, please contact
me.
>
>
> Regards,
> Mike
>
> Michael Fiedler
> IBM Rational Software
> fiedler at us.ibm.com
> 919-254-4170_______________________________________________
> 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/20120816/e155c992/attachment-0003.html>