OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-ccm message

[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:comment-tabpanel&focusedCommentId=62656#comment-62656 ] 

James Amsden commented on OSLCCCM-23:

In OSLC Core 3.0, Resource Shape, oslc:range is "For object properties, specifies what the target resource type is expected to be, but that is not necessarily the case." So defining oslc_cm:status to have oslc:range oslc_cm:Status 1) does not limit the status values, servers are free to create additional enumeration literals (instances or individuals with rdf:type oslc_cm:Status), or 2) to use a subClassOf Status, or use an entirely different type. 

However, the implication of this definition of oslc:range would seem to imply that the range can't be an object type and have oslc:valueType be string at the same time. 

So to maintain backward compatibility, CM 3.0 should keep oslc_cm:status a string and introduce new property for enumerated status values if it is felt this would be useful and not conflict with some future extension of CM that did model the lifecycle state transitions of a ChangeRequest.

It seems safe that the state of a ChangeRequest would be represented by a URL, that is, an object property. So this should be a safe thing to add and likely wouldn't conflict with a state machine for modeling valid states and transitions.

> 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 with values 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 remove oslc_cm:Status, and change the range of oslc_cm:status to xsd:String. 
> Also, the CM 2.0 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]