[oslc-cm] OSLC Change Management 2.0 Specification is in Convergence and Ready for further Review

[Steve K Speicher]

Hi Frank,

I have already logged an issue to update the language that may add 
confusion about how state predicates are modified via an action, since 
there are no action semantics defined.

The addition of a workflow model is not in scope for the current set of 
specifications.  Perhaps it would be better to understand the scenarios 
that you have that support the need for exposing the details of a workflow 
model and what aspects of that model are used for various scenarios.  As 
we strive to keep these integrations as loosely-coupled as possible, I'd 
like to better understand how we can achieve your scenarios with methods 
we have in place or need to develop.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: Frank Schophuizen <fschophuizen at gmail.com>
> To: oslc-cm at open-services.net
> Date: 05/29/2010 02:33 AM
> Subject: Re: [oslc-cm] OSLC Change Management 2.0 Specification is 
> in Convergence and Ready for further Review
> Sent by: oslc-cm-bounces at open-services.net
> 
> Hi Stev,
> 
> I have given it a second though, especially the phrase "May be a 
> read-only field that gets modified by performing an action".
> From this sentence I conclude that "status" is a side effect of "an 
action".
> 
> The workflow defines what actions are allowed. But since "an action"
> is not defined in the (this version of) spec, we cannot define which
> actions are allowed and which are disallowed in a particular state. 
> However, although it the State Predicate section mentions "Probably 
> the most important property of a Change Request is the status 
> property" (and I agree with this statement!), there is nothing in 
> the spec that supports this statement. So why is it there?
> 
> Oliver Berger wrote:
> * State predicate properties : that is far from clear and needs examples
> I think... I'd be very much annoyed to have to implement such specs at
> the moment for our Mantis add-on ;)
> 
> If we look at current providers of Change Management tools, they all
> have a workflow that defines the state transitions that are allowed 
> (regardless of the semantics of each state or state transition, 
> which is a matter of interpretation by the users/customer) and most 
> of they allow customizing the workflow. Without the workflow, the CM
> service becomes state-less and the status attribute becomes (already
> is?) a ordinary value, like any other attribute.
> In addition, the workflow determines which attributes are mandatory,
> which are optional and which are forbidden to fill, and even which 
> combination of values are allowed. Even more, the workflow must be 
> consistent that field that are mandatory "earlier" in the workflow 
> are still mandatory "later" in the workflow. The consumer may not 
> trust an attribute to be filled with a realistic value if the 
> workflow permits changing the value to unrealistic values earlier in
> the workflow.
> 
> So I think that the spec should not only define the Change Request 
> resource data model, but also the Workflow data model. The Workflow 
> model should be a state transition model with a single entry point 
> (submission of a new CR), may have multiple exit points (e.g. 
> rejected CR and close&implemented CR), and may have loops 
> (transitions to "earlier" states). For each state, the model defines
> which other states can be "reached" or which "actions" are allowed 
> to transit the state, and which attributes are mandatory/optional/
> forbidden. The service provider allows modification of the Workflow 
> model (ie. it is not a fixed Workflow model), the service provider 
> must provide an operation to validate the model for consistencies 
> and report inconsistencies (on state transitions and the CR attributes).
> 
> Regards,
> Frank.
> 
> -- 
> TOPIC Embedded Systems
> P.O. box 440, NL-5680 AK Best
> Netherlands
> Phone (+31) 499 336979
> Fax   (+31) 499 336970

> Hi Frank, 
> 
> Thanks for the feedback. 
> 
> For the scenarios we were setting out to define in the CM 2.0 spec, 
> there wasn't a pressing need for exposing the entire workflow.  The 
> status property for CM 2.0 is more intended as an informational 
> field, much like dc:title.   The state predicates are used to define
> the overall status of a change request. 
> 
> Do you have some integration scenarios where we would need to expose
> the workflow?  Do you see this workflow being exposed as a read-only
> "informative" resource only or also a model to transition states? 
> 
> Thanks,
> 
> Steve Speicher | IBM Rational Software | (919) 254-0645
> 
> _______________________________________________
> Oslc-Cm mailing list
> Oslc-Cm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net