[OASIS Issue Tracker] (OSLCCCM-28) Need a decomposition reference

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

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

Martin Sarabura commented on OSLCCCM-28:
----------------------------------------

I suppose we can play devil's advocate and ask why there are any relationships listed at all in the vocabulary - why for instance we support tracksRequirement, implementsRequirement and relatedTestScript - though the latter one is marked currently as "archaic" which sounds like "deprecated" but perhaps is something different. I think the motivation is that if we expect it to be a relatively common attribute then we want to ensure that implementers use the same term so that all implementations can be interoperable out of the box without any need for discovery and shape parsing. Decomposition or delegation-based workflow is common, best practice even. Perhaps more common than tracksRequirement, which frankly I don't understand. Where do you draw the line, and what is the decision process?

If we don't have a specific recommendation for this scenario then perhaps we should have a vocabulary of common relationships to which any OSLC implementer can refer when putting together a solution. Should the core vocabulary be augmented by common relationship attributes such as "decomposesTo", "verifiedBy", "validatedBy", "assignedTo", "augmentedBy", "contains", and so on? Presumably most if not all of these terms will already exist in some open vocabulary in which case maybe all we have to do is pull together a list of common terms. That would solve the need to come up with common relationship names without becoming overly prescriptive within a domain. Similar to rfc 5988 with the list of standard relations http://www.iana.org/assignments/link-relations/link-relations.xml

This is more of a philosophical question really - I apologize if it has been addressed already or is part of our terms of reference.

> Need a decomposition reference
> ------------------------------
>
>                 Key: OSLCCCM-28
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-28
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Bug
>          Components: Change Management
>            Reporter: Martin Sarabura
>
> There is currently an attribute called "relatedChangeRequest" which is described as a loose coupling to some other resource. By its name it seems to suggest that the other resource is likely going to be a "Change Request". While not stated explicitly, here "change request" is probably intended to be a generic reference to either the explicit type ChangeRequest or any of its subtypes.
> An "informational" link to some other resource is perfectly fine so this attribute has its place. However the PTC CM tools have the notion of a waterfall decomposition where the initial defect or enhancement is translated from "voice of the customer" to internal voice as a change request, which gets authorized via workflow to be a change notice. Finally, change notices contain one or more ordered tasks that must be completed in order for the initial request to be satisfied. This kind of decomposition link has a very different meaning than an informative link - it encapsulates a workflow. As such, and since I'm confident that this is a reasonably common feature, I believe a new relationship should be added to the spec.



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