| Review
Comment | Status | Actions
left |
- Copyright notice should
be 2018
Should
be produced by ReSpec | Jad:
It is already “Copyright © OASIS Open 2018. All Rights Reserved.” Under
the “Notices” section. | Martin:
Can you identify if this is still
a problem? |
- Sec 1 4th sentence:
… were created by the OSLC Domains TC.
| Jad:
I did the suggested change, but not closed yet.
| Martin:
A sanity check: the scenarios and
specs were created under open-services (not exactly this domains
TC). Is it still OK to take the suggested text? |
Terminology section should
be marked Non-normative and maybe use same formatting as in https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/config/oslc-config-mgt.html#terminology?I think the convention
is that every non-normative sections should be marked as such. We may have
treated nested sections of non-normative sections as non-normative, but
perhaps we shouldn't do that. A non-normative section could contain a normative
subsection, and there's no way to indicate that other than by not including
the non-normative tag.Jad:
A change is done, but not closed yet
| Martin:
Sanity check: The whole of Introduction
section is marked non-normative. If we only mark Terminology as non-normamtive,
what does this mean for the other subsections? ConfigMangement also only
mark some subsections as non-normative.
| |
| Review
Comment | Status | Actions
left |
- Use a more current date
under the title?
Positioning
of the date is governed by OASIS publishing guidelines. Generally ReSpec
puts in the right place. The actual date value is based on the document
state and when it is published, or when votes are taken to change state. | | Martin:
Can you please clarify? I think
the date is automated. |
- Same notes re status, copyright
notice
I thought
this was covered by ReSpec | Jad:
* Status text is not controlled
by the RM document.
* It is already “Copyright © OASIS
Open 2018. All Rights Reserved.” Under the “Notices” section. Any other
place you are referring to? | Martin:
Can you identify if this is still
a problem? |
- Shouldn’t we have a non-normative
recommendation for how to represent a tree structure in these collections?
The only real option available here is the oslc_rm:uses property. Presumably
it can include another requirements collection; thus creating a hierarchy.
Since it is the only option then presumably everybody will figure that
out but it’s such a common scenario (ReqIF, Integrity LM) that it seems
worth mentioning – or some other approach if oslc_rm:uses is not desirable
for some reason.
RequirementCollection
has the oslc_rm:uses property, so it supports hierarchies of collections.
Not sure this needs further explanation. RDNG does not appear to allow
collections to be added to collections. | | Martin:
We have discussed this during a
telco but don’t recall a decision.
I suggest we don’t add such text
at this stage.
|
- Another philosophical question,
what is the granularity of Requirements Collections in relation to Service
Provider (or LDPC)? I can see them being identical, or, it could be that
there are many requirements collections within a given service provider.
What would be our (presumably non-normative) recommendation for how to
design this?
There
is no connection between service providers, LDPCs or RequirementCollection.
There is no constraint that the requirements in a collection have to be
from the same service provider, but I suppose they often are. | | Martin:
We have discussed this during a
telco but don’t recall a decision.
I suggest we don’t add such text
at this stage.
|