These links were deprecated as part of the resolution of Issue on redundant inverse predicates July 2013. However, these deprecated properties are supported by ELM EWM.
OSLC CM 3.0 does not define any corresponding properties representing links from the other direction. This is because we were attempting to follow link guidance best practices and only define the links from one direction to avoid backlinks and data redundancy issues, and therefore removed the deprecated properties. It could also be that when the CM 3.0 spec was standardized, we were not aware any implications for OSLC Configuration Management and link ownership issues.
With the introduction of OSLC Configuration Management 1.0, and the fact that OSLC Change Management resources are not versioned resources, we have introduced a situation where these deprecated properties need to be added back to OSLC CM 3.0.
As background, EWM ChangeRequests (i.e. work items) are not versioned. Rather they are associated with change sets that are delivered to a stream in order to transition the configurations of resources from one state to another. Work items describe what was done, by whom, why and when for all the changes in a change set. Change sets are applied to resources to create new versions.
ChangeRequests can link to or be associated with a change set in the configuration contributed by another tool. ChangeRequests are also linked directly to requirements they implement, designs that inform the work, test cases that validate the work, etc. For configuration aware tools, unversioned ChangeRequests need to link to specific versions of configuration aware tool managed artifacts.
Any references from a versioned resource to an unversioned resource cannot be reliably reconstructed. Any change to the unversioned resource would be seen in all configurations of the referencing versioned resources, making it impossible to save and restore the snapshots of the links. Baselines could not be entirely immutable since things they link to could change or be deleted.
So I propose that the deprecated and removed oslc_cm properties be added back to OSLC CM 3.1 and we proceed with this specification revision soon.
We still need to decide how to specify in a discoverable way which links (i.e. assertions) should be stored by which server, and how to designate the forward (should be stored) and inverse (should not be stored) properties. That can be part of the Linking Profile effort, but should not impact the CM 3.1 spec.
QM defines the following properties:
oslc_qm:relatedChangeRequest oslc_qm:testsChangeRequest oslc_qm:affectedByChangeRequest oslc_qm:blockedByChangeRequest oslc_qm:affectedByChangeRequest
The OSLC CM 2.0 specification defines properties representing links from the other direction:
oslc_cm:testedByTestCase oslc_cm:affectsTestResult oslc_cm:blocksTestExecutionRecord oslc_cm:relatedTestExecutionRecord oslc_cm:relatedTestCase oslc_cm:relatedTestPlan oslc_cm:relatedTestScript
These links were deprecated as part of the resolution of Issue on redundant inverse predicates July 2013. However, these deprecated properties are supported by ELM EWM.
OSLC CM 3.0 does not define any corresponding properties representing links from the other direction. This is because we were attempting to follow link guidance best practices and only define the links from one direction to avoid backlinks and data redundancy issues, and therefore removed the deprecated properties. It could also be that when the CM 3.0 spec was standardized, we were not aware any implications for OSLC Configuration Management and link ownership issues.
With the introduction of OSLC Configuration Management 1.0, and the fact that OSLC Change Management resources are not versioned resources, we have introduced a situation where these deprecated properties need to be added back to OSLC CM 3.0.
As background, EWM ChangeRequests (i.e. work items) are not versioned. Rather they are associated with change sets that are delivered to a stream in order to transition the configurations of resources from one state to another. Work items describe what was done, by whom, why and when for all the changes in a change set. Change sets are applied to resources to create new versions.
ChangeRequests can link to or be associated with a change set in the configuration contributed by another tool. ChangeRequests are also linked directly to requirements they implement, designs that inform the work, test cases that validate the work, etc. For configuration aware tools, unversioned ChangeRequests need to link to specific versions of configuration aware tool managed artifacts.
Any references from a versioned resource to an unversioned resource cannot be reliably reconstructed. Any change to the unversioned resource would be seen in all configurations of the referencing versioned resources, making it impossible to save and restore the snapshots of the links. Baselines could not be entirely immutable since things they link to could change or be deleted.
So I propose that the deprecated and removed oslc_cm properties be added back to OSLC CM 3.1 and we proceed with this specification revision soon.
We still need to decide how to specify in a discoverable way which links (i.e. assertions) should be stored by which server, and how to designate the forward (should be stored) and inverse (should not be stored) properties. That can be part of the Linking Profile effort, but should not impact the CM 3.1 spec.