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

[Frank Schophuizen]

Excuse my for the many typos, but one typo is essentially wrong:
"The service provider allows modification of the Workflow model " should be
"*If the* service provider allows modification of the Workflow model "

Frank.

On Sat, May 29, 2010 at 8:33 AM, Frank Schophuizen
<fschophuizen at gmail.com>wrote:

> 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
>>
>
>
>


-- 
TOPIC Embedded Systems
P.O. box 440, NL-5680 AK Best
Netherlands
Phone (+31) 499 336979
Fax   (+31) 499 336970
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20100529/a80690cd/attachment-0003.html>