OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-domains message

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

Subject: RE: [oslc-domains] TC review of draft migrated Requirements Management Specification



I have made some changes in response to Martin & Mark’s review comments. Attached is the status of what is left to do. Is there a way I can post this document somewhere, so we can avoid emailing different versions of it?


Besides the action to write an abstract, I would like a quick followup on most other items before we can proceed.




Jad El-khoury, PhD

KTH Royal Institute of Technology

School of Industrial Engineering and Management, Mechatronics Division

Brinellvägen 83, SE-100 44 Stockholm, Sweden

Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45

jad@kth.se, www.kth.se


From: oslc-domains@lists.oasis-open.org [mailto:oslc-domains@lists.oasis-open.org] On Behalf Of Schulte, Mark D
Sent: 08 March 2018 22:47
To: oslc-domains@lists.oasis-open.org
Subject: RE: [oslc-domains] TC review of draft migrated Requirements Management Specification


My comments:



1)      General

a.       I thought we were going to client and supplier instead of consumer and service provider but there are still instances of the former references scattered throughout the document.

2)      Specification URIs

a.       There are a couple of references in this section to “OASIS OSLC Lifecycle Integration Domains TC”.  The official name of the TC appears to be “OASIS OSLC Lifecycle Integration for Domains TC”.

3)      Related Work

a.       It might be good to add a couple of lines on how this is related to the 2.0 Specification and what has/has not been touched.  If more appropriate, that perhaps could also be part of the currently blank Abstract section.

4)      Citation Format

a.       When does “OASIS Working Draft 01“ get dropped?  Surely we don’t release this with ‘working draft’ in the document?

5)      Notices

a.       In paragraph 5, there are two uses of “infringed”.  I think it would read better if instead we used “infringed upon”.

b.       In paragraph 7, it says “OASIS’ procedures”.   I’m not sure the possession marker is needed here.

6)      Base Requirements

a.       Paragraph 1, Syntax…..addition à “recommendations in both of these specifications”

7)      2.5 Authentication

a.       Reference to OSLC CM servers…..instead of OSLC RM servers

8)      2.6 Error Responses

a.       See previous comment

9)      2.9 Labels for Relationships

a.       Change “…it may be helpful to display an informative and useful textual label instead of or in addition to the URI of the predicate and or object.” To “…it may be helpful to display an informative and useful textual label instead of, or in addition to, the URI of the predicate and/or object.”

b.       For Link definition…..”resource, only then OSLC servers may support” doesn’t sound right.

10)   4.1 Server Resources – “outwith” can’t be right.  Should that have been “within”.

11)   4.3 Query Capabilities – misspelling, “oslc:resutls

12)  Acknowledgements – Nicholas Kruk should not have a “?” after his name.  First and last names should be separated by a space.  Might consider listing people alphabetically but up to you since the list is short.




13)   1.2 Terminology

a.       First paragraph might be improved as a bulleted list.

14)   2.1.4 RequirementCollection

a.       “A collection uses includes zero or more requirements”……better, more accurate?

15)   All of the relationship type descriptions seem like they should be consistently described and using the same example as the title.

a.       For instance, instead of “a defect may be said to affect a requirement” as an example of “affectedby” say instead “a requirement may be affected by a defect.”

                                                               i.      From a consistency standpoint, 2.1.8 for “satisfiedBy” does in fact follow the format but the others do not.  At a minimum, this is inconsistent.

b.       2.1.12 says “For example, a test plan may be said to validated a requirement collection.”    Correct the grammar here.

16)   3.1 Resource:Requirement

a.       Suggest a period instead of a comma in the following sentence:

                                                               i.      Requirement resource properties are not limited to the ones defined in this specification, service providers may provide additional properties.

b.       Description section, need to fix grammar here – “or possed by a solution component,”

c.        Add ‘or to’ here à “……achieve an objective, or to satisfy a contract, standard, specification, or other formally imposed documents.”

d.       In the description column, foaf:person is referenced.  Shouldn’t resource names there follow the same font convention as other references such as oslc:AnyResource



Mark D. Schulte

OSLC MS Steering Committee, Domains TC

Boeing Defense Systems

The Boeing Company


Office: +1 314-777-7331





From: oslc-domains@lists.oasis-open.org [mailto:oslc-domains@lists.oasis-open.org] On Behalf Of Jim Amsden
Sent: Thursday, March 01, 2018 10:31 AM
To: oslc-domains@lists.oasis-open.org
Subject: [oslc-domains] TC review of draft migrated Requirements Management Specification


The Requirements Management 2.1 specification working draft document is ready for OASIS Domains TC review. Thanks Mark and Jad for getting this document ready. The document can be accessed at:


This is a multi-part document including the specification and vocabulary documents. Both should be reviewed and can be accessed from the link above.

TC members should consider the following when reviewing these documents:

1. Verify OASIS document formatting, and formatting vitality (HTML issues, section/subsection issues, etc.)

2. Verify the Base Requirements section is correctly migrated from version 2.0: http://open-services.net/bin/view/Main/RmSpecificationV2

3. Verify the appropriate document sections from the version 2.0 specification have been migrated to the appropriate sections in the 2.1 specification

4. Verify the vocabulary and shapes are consistent with the HTML tables in the 2.0 specification

5. Verify the overall structure, completeness and readability of the specification

6. Ensure compatibility with OSLC core 2.0 and 3.0, and that no semantic or implementation dependent changes have been made in the 2.1 specification.

These and other guidelines are summarized on the OSLC Domains TC Wiki: https://github.com/oasis-tcs/oslc-domains/wiki

Please send your review comments to this mailing list. Let's try to get the RM spec reviewed within the next two weeks. Then we will create a committee specification draft and submit for public review.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

Attachment: OSLC RM Reviews.docx
Description: OSLC RM Reviews.docx

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