Frank Schophuizen <[email protected]> wrote on 05/23/2010 04:19:06 PM:
> From: Frank Schophuizen <[email protected]> > To: [email protected] > Date: 05/23/2010 04:19 PM > Subject: Re: [oslc-cm] OSLC Change Management 2.0 Specification is > in Convergence and Ready for further Review > Sent by: [email protected] > > The following remark on the CmSpecificationV2 section is about the > State Predicates section, in particular this sentence > > "Status" specifies the location of a Change Request in a workflow > > The spec does define the oslc_cm:status property of a Change Request > Resource, but there is no definition of a workflow. The introduction > does explain part of the problem though in: > > The problem is that different CM service providers use different > properties (or even a set of properties) and different values to > represent the change request's state. Even providing access to meta > data does not help because knowing all possible state values does > not reveal the semantics of a state. > > My remark is that even if you don't know the semantics of each > individual status value, shouldn't there be at least a way to > interrogate the server about the workflow. In other words, what good > is it to know a location if you don't know the coordinate system forlocations? 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
