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-25) CM Section 4.5 Usage Identifiers should be deprecated


     [ https://issues.oasis-open.org/browse/OSLCCCM-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Amsden updated OSLCCCM-25:
--------------------------------

    Description: 
CM 1.0 and 2.0 attempted to avoid using RDF classes and subclasses to define different types of ChangeRequest. The goal was to be flexible and open, and allow servers to define whatever types of change request met their client's needs.

CM 1.0 used dcterms:type - a string value was used to define the ChangeRequest type. This was deprecated in OSLC CM 2.0, but is still in common use.

CM 2.0 used rdf:type, with at least one value of http://open-services.net/ns/cm#ChangeRequest.

CM 3.0 continues to use rdf:type and define specific rdfs:subClassOf oslc_cm:ChangeRequest to define new kinds of change request.


CM 2.0 also uses oslc:usage with individual values oslc_cm:defect, planItem, task, requirementsChangeRequest are defined in CM 2.0 to allow servers to distinguish different services of a ServiceProvider. These might be used to define creation factories for specific CM 3.0 ChangeRequest subtypes.


  was:
CM 1.0 and 2.0 attempted to avoid using RDF classes and subclasses to define different types of ChangeRequest. The goal was to be flexible and open, and allow servers to define whatever types of change request met their client's needs.

There were two common approaches used:

1. dcterms:type - a string value was used to define the ChangeRequest type. This was deprecated in OSLC CM 2.0, but is still in common use.

2. oslc:usage with individual values oslc_cm:defect, planItem, task, requirementsChangeRequest are defined in CM 2.0 to distinguish different kinds of ChangeRequest

CM 3.0 introduces a third approach:

3. Define specific rdfs:subClassOf oslc_cm:ChangeRequest to define new kinds of change request.

CM 3.0 should deprecate the use of oslc:usage to distinguish different kinds of ChangeRequest


> CM Section 4.5 Usage Identifiers should be deprecated
> -----------------------------------------------------
>
>                 Key: OSLCCCM-25
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-25
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>
> CM 1.0 and 2.0 attempted to avoid using RDF classes and subclasses to define different types of ChangeRequest. The goal was to be flexible and open, and allow servers to define whatever types of change request met their client's needs.
> CM 1.0 used dcterms:type - a string value was used to define the ChangeRequest type. This was deprecated in OSLC CM 2.0, but is still in common use.
> CM 2.0 used rdf:type, with at least one value of http://open-services.net/ns/cm#ChangeRequest.
> CM 3.0 continues to use rdf:type and define specific rdfs:subClassOf oslc_cm:ChangeRequest to define new kinds of change request.
> CM 2.0 also uses oslc:usage with individual values oslc_cm:defect, planItem, task, requirementsChangeRequest are defined in CM 2.0 to allow servers to distinguish different services of a ServiceProvider. These might be used to define creation factories for specific CM 3.0 ChangeRequest subtypes.



--
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]