[OASIS Issue Tracker] (OSLCCCM-32) Ability to associate a set of change requests to a parent change request

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCCM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65674#comment-65674 ] 

Nick Crossley commented on OSLCCCM-32:
--------------------------------------

For ordering, see the W3C Note https://www.w3.org/TR/ldp-paging/. In particular, note the sentence:

"[LDP] does not provide any particular support for server ordering of members in containers, because any client can order the members in any way it chooses based on the value of any available property of the members."

I believe this sentiment applies equally well to any OSLC link or member properties, whether the parent is or is not an LDPC. So, I do not believe OSLC need to define a separate ordering of child change requests, but we should allow clients and servers to follow the recommendations of this W3C note on ordering of pages, and ordering of contents between pages.

> Ability to associate a set of change requests to a parent change request
> ------------------------------------------------------------------------
>
>                 Key: OSLCCCM-32
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-32
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Improvement
>          Components: Change Management
>            Reporter: Martin Sarabura
>            Assignee: James Amsden
>
> The current spec allows one to associated one or more change requests with the current change request either as a neutral association (relatedChangeRequest) or to inform impact analysis (affectsPlanItem) or as a decomposition (affectedByDefect). None of these relationships represents a container relationship whereby the current change request is decomposed into a series of tasks that must be done in order to satisfy the change request. This is a significant gap that can't be filled by repurposing one of the existing relationships because a) there may be a need to represent one of the other relationships in addition to a container relationship and b) there is no easy way to indicate how the client should interpret the relationship anyway. Note that task order is significant - not sure how it should be represented. Finally, there is (probably?) no need to include the same task twice on the same list. However, I can see a need for a task to show up on multiple containers so that it can be completed by the first person to get to it.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)