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 >
