[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
|
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”.
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
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
Office: +1
314-777-7331 From: oslc-domains@lists.oasis-open.org [mailto:oslc-domains@lists.oasis-open.org]
On Behalf Of Jim Amsden 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: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]