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

[Frank Schophuizen]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20100529/18da1ee6/attachment.html>