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-26) Clarify OSLC extensibility of CM specification

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

James Amsden commented on OSLCCCM-26:

I added: "This specification defines the ChangeRequest superclass, and a number of specific, commonly occurring subclasses and properties. Servers may define additional ChangeRequest subclasses and provide additional properties as needed."

to section 2. Change Management Vocabulary Terms.

Is this sufficient?

> Clarify OSLC extensibility of CM specification
> ----------------------------------------------
>                 Key: OSLCCCM-26
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-26
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Bug
>          Components: Change Management
>            Reporter: Martin Sarabura
> Because the CM spec lists a number of values for types, attributes and values, a casual reader may infer that the CM spec is supposed to be complete. The reader may not fully understand the OSLC philosophy and is actively mapping the spec onto their own use cases while reading the spec. If the mapping comes up short they may conclude that the spec is inadequate. Thus I think it is important to state in the Vocabulary document at least, that the spec is not intended to satisfy all possible scenarios and that a client should consult the resource shape of an implementation to see how it has extended the spec.
> For example:
> 1. By listing Task, Defect, Enhancement and ReviewTask as subclasses of ChangeRequest it is implied that these are considered the "correct" types to use;
> 2. The list of states, severities and priorities is small and almost certainly incomplete for an enterprise-ready implementation; and
> 3. The listed resource constraints are likely incomplete for various scenarios that the reader considers "obvious"

This message was sent by Atlassian JIRA

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