On the last two points, I’m OK with not changing the text at this time because our goal is to apply a light hand to the existing spec to get it published
under the OASIS organization. Maybe this looks like a couple of wiki articles we can line up, right?
I think we need to start providing v3 guidance to give additional depth to our OASIS content, and these would be good quick articles.
Re marking as non-normative, I think it’s correct now: Most sections are indeed normative and by default a section that is not prefaced with the
non-normative disclaimer is assumed to be normative. Section 2 being non-normative does not imply that 2.1 is also non-normative.
The only additional non-normative disclaimer I would add is for Appendix A
Regards, Martin
From: oslc-domains@lists.oasis-open.org [mailto:oslc-domains@lists.oasis-open.org]
On Behalf Of Jad El-Khoury
Sent: Thursday, April 19, 2018 3:57 PM
To: Nicholas Crossley <nick_crossley@us.ibm.com>
Cc: oslc-domains@lists.oasis-open.org
Subject: RE: [oslc-domains] [OSLC Domains] Actions on the TC reviews
Thanks Nick! Got it.
I have updated the RM document based on discussions/decisions today. We are almost done.
What is left? I have 2 sanity checks, 3 problems I cannot find/understand, 2 suggestions for text we need to decide if
we want to introduce or not.
Martin!
Maybe I can get your input on those?
All!
What is your input on the last 2 entries?
Specification:
Review Comment
|
Status
|
Actions left
|
- Copyright notice should be 2018
|
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
?
|
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.
|
Vocabulary:
Review Comment
|
Status
|
Actions left
|
- Use a more current date under the title?
|
|
Martin:
Can you please clarify? I think the date is automated.
|
- Same notes re status, copyright notice
|
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.
|
|
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?
|
|
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.
|
______________________________
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: Nicholas Crossley [mailto:nick_crossley@us.ibm.com]
Sent: 19 April 2018 16:55
To: Jad El-Khoury <jad@kth.se>
Cc: Nicholas Crossley <nick_crossley@us.ibm.com>;
oslc-domains@lists.oasis-open.org
Subject: RE: [oslc-domains] [OSLC Domains] Actions on the TC reviews
I meant that I believe the original text was intended to be 'posed'. With an inanimate 'solution component' as the thing doing the posing, there is not much difference
between 'imposed' and 'posed', and 'imposed' is both more common and consistent with the usage later in the sentence.
Nick.
From: Jad El-Khoury <jad@kth.se>
To: Nicholas Crossley <nick_crossley@us.ibm.com>
Cc: "oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date: 04/19/2018 04:53 AM
Subject: RE: [oslc-domains] [OSLC Domains] Actions on the TC reviews
Sent by: <oslc-domains@lists.oasis-open.org>
Thanks Nick
with “I read this as 'posed'”, I assume you mean I read this as 'imposed', right? Your suggested text says ‘imposed”, so wondering which you meant.
I will otherwise also take it your other suggested changed. But won’t have time to introduce them before our telco today
/Jad
From: Nicholas Crossley [mailto:nick_crossley@us.ibm.com]
Sent: Thursday, 19 April 2018 00:53
To: Jad El-Khoury <jad@kth.se>
Cc: oslc-domains@lists.oasis-open.org
Subject: Re: [oslc-domains] [OSLC Domains] Actions on the TC reviews
Jad,
Here are my comments:
It is perfectly acceptable for us to correct, expand, or clarify descriptions of existing vocabulary terms, properties in shapes, etc. - in fact, we have done so for Core 3.0 in several areas. We can also (of course) add new terms. We cannot remove existing
terms, and we should not completely change the meaning of an existing term.
In the new text about relationship properties and the reification technique, personally I would prefer to see some form of caution about the security/access concern - perhaps along these lines:
Implementers should take care that including the label or other properties of the target of a relationship within the RDF published for the source of that relationship does not expose data to which the reader should not have access.
However, I do not feel strongly enough about this to insist on such a change.
"possed by a solution component" - I read this as 'posed'. Since we also use 'impose' later in the description, I suggest we be consistent and use that here, so the full text would read:
A condition or capability needed by a stakeholder, or imposed by a solution component, to address a need, solve a problem, achieve an objective, satisfy a contract, standard, specification, or other formally imposed documents.
Nick.
From: Jad El-Khoury <jad@kth.se>
To: "oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date: 04/03/2018 03:49 PM
Subject: [oslc-domains] [OSLC Domains] Actions on the TC reviews
Sent by: <oslc-domains@lists.oasis-open.org>
Dear all,
I have now made the suggested changes to the RM specs, raised from the latest discussion on “Reified relationships in RM domain”.
I order to finalize the review comments I received from Martin & Mark, I would love to get your input on some of the remaining issues.
Martin, Mark, Jim & Nick!
Can I ask for your input on specific comments raised in the document https://github.com/oasis-tcs/oslc-domains/blob/master/rm/OSLC%20RM%20TC%20Reviews.docx
It is also attached for your convenience.
I have tagged each row where I need your input with your name.
Please feel free to simply add your respond in that same column “action left” and I can take it from there.
Otherwise, the only remaining issue that we are awaiting a decision from the Core TC relates to “resource formats” (rdf/xml, turtle).
regards
______________________________
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
[attachment "OSLC RM TC Reviews.docx" deleted by Nicholas Crossley/Seattle/Contr/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=GjwCRqtPs7eIJIYQ2Ts1FtMhYFjprGd8jgbGBRR0LKQ&m=JbJZyX88tm__0WwcHpVbSTiG5NTHR2foggRWlbjtq-g&s=VJmi0btt1hIAhJbjmlQHcMsSnI5Q6tszlqR1jymPEKY&e=