My comments:
Specification:
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.
Vocabulary:
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: [mailto:]
On Behalf Of Jim Amsden
Sent: Thursday, March 01, 2018 10:31 AM
To:
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:
http://htmlpreview.github.io/?https://github.com/oasis-tcs/oslc-domains/blob/master/rm/requirements-management-spec.html
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
919-525-6575
