[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCCM-23) oslc_cm:status range is String in CM 2.0 and can't be changed to oslc_cm:Status
[ https://issues.oasis-open.org/browse/OSLCCCM-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Amsden updated OSLCCCM-23: -------------------------------- Proposal: Currently CM 3.0 has at least two, and possibly three overlapping and perhaps inconsistent ways to model the status/state of a ChangeRequest: 1. oslc_cm:status - with unspecified, open string values 2. oslc_cm:state - with oslc:range oslc_cm:State and a standard set of individuals defining a minimal set of standard, states 3. "State Predicates": ChangeRequest Boolean properties oslc_cm:closed, inProgress, fixed, approved and reviewed CM 3.0 should simplify and normalize this while maintaining compatibility with CM 2.0. The proposed solution is to: 1. leave oslc_cm:status unchanged and with valueType String, but deprecate the property. 2. Retain the State Predicate boolean properties oslc_cm:closed, inProgress, fixed, approved, reviewed, etc. These are typically read-only properties that are computed from other values of the ChangeRequest to provide a standard summary of information about the state of the ChangeRequest. oslc_cm:state would likely be used to calculate this value, but oslc_cm:status and other properties could be used as well. 3. Introduce a new property oslc_cm:state with oslc:range oslc_cm:State whose individuals define an extensible standard set of change request states. was: Currently CM 3.0 has at least two, and possibly three overlapping and perhaps inconsistent ways to model the status/state of a ChangeRequest: 1. oslc_cm:status - with unspecified, open string values 2. oslc_cm:status - with oslc:range oslc_cm:Status and a standard set of individuals defining a minimal set of standard, states 3. "State Predicates": ChangeRequest Boolean properties oslc_cm:closed, inProgress, fixed, approved and reviewed CM 3.0 should simplify and normalize this while maintaining compatibility with CM 2.0. A proposed solution is to: 1. leave oslc_cm:status unchanged and with valueType String, but deprecate the property. 2. Deprecate the State Predicate properties oslc_cm:closed, inProgress, fixed, approved, reviewed 3. Introduce a new property oslc_cm:state with oslc:range oslc_cm:State whose individuals define an extensible standard set of change request states. > oslc_cm:status range is String in CM 2.0 and can't be changed to oslc_cm:Status > ------------------------------------------------------------------------------- > > Key: OSLCCCM-23 > URL: https://issues.oasis-open.org/browse/OSLCCCM-23 > Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC > Issue Type: Bug > Components: Change Management > Reporter: James Amsden > Priority: Blocker > > Early in the CM 3.0 spec development there was a plan to use Actions to define valid state transitions on property oslc_cm:status. Because Actions was deferred in Core 3.0, we decided to defer its use in CM 3.0. > As a compromise, we created an enumeration oslc_cm:Status class with individuals such as oslc_cm:Closed, Inprogress, etc. and used that as the range for oslc_cm:status in order to at least define a minimal set of expected values. > However, oslc_cm:status is a String in CM 2.0 and this would be a breaking change. So we have to rename oslc_cm:Status to oslc_cm:State, and set the range of oslc_cm:status to xsd:String. > Also, the CM 2.0 "State Predicate" boolean properties oslc_cm:closed will need to be added back. We should discuss this and see if we think these should be deprecated, and if we can retain oslc_cm:status and xsd:String for oslc_cm:status. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]