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 <[email protected]>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
