RE: [oslc-domains] Modified: OSLC Domains TC Weekly Meeting

Mark,
I think our overall goal is to have
a consistent set of standards without introducing a  lot of upheaval
in the OSLC tools community. To that end, we attempted to ensure (but without
explicit reference implementations and formal testing) OSLC Core 3.0 is
backward compatible with Core 2.0. 

There are a couple of somewhat glaring
areas where this consistency will be a challenge. The first is serialization
formats. OSLC 2.0 requires RDF/XML (and that's what most tools use) while
OSLC 3.0 requires Turtle and JSON-LD (as required by LDP 1.0). Now Domain
specifications are free to add or promote constraints - so it is fine for
a domain specification to change RDF/XML from MAY to MUST. But a domain
specification should not change Turtle MUST to a MAY. That's the issue
we have migrating the old specs. Changing Turtle to MUST would be a breaking
change.

The other issue is how members of a
collection are captured. OSLC Core 2.0 didn't seem to address this, instead
defining specific resource formats for service provider catalog, service
provider and service resources. It looks like OSLC 1.0 query did introduce
some notion of RDF membership, but this wasn't carried forward to OSLC
Query 2.0 - its output format is just a set of matching triples in whatever
RDF serialization format the server is able to support. OSLC Core 3.0 introduces
LDPCs for membership, but retains OSLC 2.0 discovery resources. So this
maintains compatibility. We still need to figure out what to do about query
results. I'm looking at that now.

As a general rule, any conflicts between
the domain specifications and OSLC Core 3.0 should be resolved by having
the domain specification overrule Core 3.0. OSLC 2.0 compatibility is more
important at this time. These conflicts can be noted in the specification
and have raised issues. Then we can let the public reviews determine if
we got it right or not.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575

From:      
 "Schulte, Mark
D" <>
To:      
 Jad El-Khoury <>,
Jim Amsden <>
Date:      
 11/21/2017 02:14 PM
Subject:    
   RE: [oslc-domains]
Modified: OSLC Domains TC Weekly Meeting

It wasn’t clear to me what
version(s) we are focusing on here.
 
I guess I would be a little
concerned that we change much of anything (that we don’t have to) from
the simple transition from the 2.0 formatting to the new OASIS format.
 I would think we would want people looking at the old and the new
in this case to quickly see that this was a format-only transition, with
essentially no changed content.   Updating too much, even to clarify
and clean things up a bit, could be confusing and so all of the introduced
changes need to be clearly outlined as what is constituting this 2.1 update.

 
There are a lot of references
in here to 3.0, which I did not think was what we were intending to introduce
here unless that is the intention and the next iteration you are working
on here??  We still need to get the 2.1 update content done first,
right?
 
From: Jad El-Khoury [mailto:]

Sent: Friday, October 27, 2017 5:19 PM
To: Jim Amsden <>
Cc: Schulte, Mark D <>
Subject: RE: [oslc-domains] Modified: OSLC Domains TC Weekly Meeting
 
Hi
Mark & Jim,
 
Attached is a new iteration
on RM, taking into account the comments below. I also took a short at updating
the Introduction.
I hope I found the right
balance when referring to Core 3.0 and 2.0. But I still find it confusing
to know when to claim RM3.0 should comply to Core3.0, without that breaking
compatibility with RM2.0.
 
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
,
www.kth.se
 
From: Jim Amsden [mailto:]

Sent: 26 October 2017 22:32
To: Jad El-Khoury
Cc: Schulte, Mark D
Subject: RE: [oslc-domains] Modified: OSLC Domains TC Weekly Meeting
 
Jad,
Comments below...

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575

From:        Jad El-Khoury
<>
To:        "Schulte,
Mark D" <>,
Jim Amsden <>
Date:        10/25/2017
06:08 PM
Subject:        RE:
[oslc-domains] Modified: OSLC Domains TC Weekly Meeting

Hi Mark & Jim.
 
After Jim integrated your changes into github, I took another round at
the document. 
 
For now, I focused on the overall structure, where I tried to identify
which parts to copy from RM2.0, and which from CM3.0.
I have some “big” questions below. Once these are in place, I thought
I can take another round, and deal with some details (abstract, etc.)
 
I thought it more efficient if we can agree on these issues first, before
I do the changes. This way I get a better understanding of the intention
of this migration effort.
 
Section “2. Base Requirements”
In the column “meaning”, RM2.0 used the terms "service" and
“Service Providers”, which is also what CM2.0 uses.
Now, CM3.0 users “servers” instead. So, I assume it is safe to use “server”
in RM3.0 as well.
Suggestion: use “server” in RM3.0.
<jra>Use RM Server where ever you see Service Provider, RM Client
where ever you see Service Consumer</jra>
 
Section “2. Base Requirements”
Is there a reason we can’t copy exactly the content of CM3.0 into RM3.0?
I noticed that CM3.0 has done some updates from CM2.0. so why not adopt
the same changes to RM3.0?
Notice here that CM3.0 introduces additional requirements (such as "Turtle
Representations" row). I assume it is safe to add it to RM3.0? Would
this still be backward compatible?
<jra>Remember we are not making any changes to RM 2.0, this is just
document maintenance. So none of the base requirements can change in any
sematically impacting way. You can format them they way you like, use titles,
order them, etc. But you can't delete any, or add any, and can't change
any MAY, MUST or SHOULD as these could all result in compatibility problems,
and would require new server and client implementations in order to become
an OASIS Standard</jra>
 
Section “2.4 Resource Formats” (and its subsections)
Again, is there a reason not to copy the content from CM3.0? I don’t see
why should the RM domain differ from CM when it comes to formats.
Note here that CM3.0 already differs from CM2.0. So, again, we can motivate
improvements to RM3.0 for the same reasons.
Plus, RM2.0 has a special set of bullets on "Query requests".
I doubt this is relevant to keep.
<jra>Same as above - CM 3.0 is different than CM 2.0 and that's perhaps
unfortunate, but investment that has already been made. When OSLC 3 was
chartered, compatibility with 2.0 was not sufficiently considered. We have
had to correct that</jra>
 
Section “2.5 Authentication”
CM2.0 states that in addition to Core, CM "SHOULD support OAUTH".
Yet, CM3.0 states SHOULD support for OpenIDConnect instead.
RM2.0 states no additional requirements, other than core. 
Suggestion: We copy CM3.0 text, stating OpenIDConnect as well.
<jra>OAuth is the more widely implemented mechanism, including in
eclipse/Lyo. You can add a SHOULD for OpenIDConnect in addition to OAuth,
that won't hurt.</jra>
 
Section “2.8 Requesting and Updating Properties” (and its subsections)
Again, any reason NOT to copy CM3.0?
<jra>Only if its 100% compatible (which I think it is)</jra>
 
Section “2.9 Labels for Relationships”
Again, any reason NOT to copy CM3.0?
<jra>Same. In fact, these section should have been included in the
template and cloned automatically.</jra>
 
Section “4. RM Server Capabilities”
Again, any reason NOT to copy CM3.0?
Notice here that RM2.0 uses terms such as Service and ServiceProviders.
While CM3.0 uses “servers”.
<jra>Same answer</jra>
 
Section “Appendix A. Version Compatibility with 2.0 Specifications”
As far as I can see, there are no changes worth mentioning between RM2.0
and RM3.0.
The current text (which I removed) relates to changes between 2.0 and 1.0.
I noticed that CM3.0 does not relate to 1.0, but 2.0. 
<jra>This section should explicitly say that there is nothing document
maintenance changes.</jra>
 
I believe these changes are relatively quick to fix
 
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
,
www.kth.se
 
From: Schulte, Mark D [mailto:]

Sent: 19 October 2017 21:17
To: Jim Amsden
Cc: Jad El-Khoury
Subject: RE: [oslc-domains] Modified: OSLC Domains TC Weekly Meeting
 
 
 
Jim, here is my cut at the updates to the original RM 2.0 specification.
 As I mentioned to you earlier, the easiest path was for me to brute
force update the html into the newer format required.  I did clean
up a few things but for the most part, I just wanted it look to like the
format I did for the AM specification earlier (which you are reviewing)
and to reflect the same technical content as the original 2.0 specification.
 
Since I had issues using github earlier and not familiar yet with ReSpec
I am sure there will be some additional post-processing to do, but maybe
Jad can help from this point as I will be on travel for the next couple
of weeks.  When rendering the document in the browser, however, I
did address the ReSpec errors/warnings which were showing up there so hopefully
that helps.  
 
Mark
 
 
-----Original Appointment-----
From: [mailto:]

Sent: Monday, October 02, 2017 1:48 PM
To: ;

Subject: [oslc-domains] Modified: OSLC Domains TC Weekly Meeting
When: Thursday, October 19, 2017 10:30 AM-11:00 AM America/New_York.
Where: 
 
 

Event
Title: OSLC
Domains TC Weekly Meeting
  ________________________________  
Date: Thursday, 05 October 2017, 10:30am to 11:00am EDT
Description
Passcode:1459670#,
US: 888-426-6840, 
International Numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=1459670&accessNumber=2158616239
Chat Room: http://webconf.soaphub.org/conf/room/oslc-domains

This meeting counts towards voter eligibility.
  ________________________________  
Agenda
Weekly meeting to facilitate migration of OSLC 2.x domain specifications
from open-services.net to OASIS. This meeting follows the OSLC Core TC
meeting.
 
  ________________________________  
Owner: Mr. James Amsden
Group: OASIS OSLC Lifecycle Integration for Domains (OSLC Domains)
TC
Sharing: This event is shared with the OASIS Open (General Membership),
and General Public groups. Public
Event Link
Recurrence
This event is part of a series with 65 more events. The next 4 events in
this series:
Thursday, 12 October 2017, 10:30am to 11:00am EDT
Thursday, 19 October 2017, 10:30am to 11:00am EDT
Thursday, 26 October 2017, 10:30am to 11:00am EDT
Thursday, 02 November 2017, 10:30am to 11:00am EDT
·     Learn more about subscribing here.

·     View the OASIS OSLC Lifecycle Integration
for Domains (OSLC Domains) TC calendar here.

·     You may receive future notifications
with updates to this event. Update the event on your calendar by accepting
the changes. 
 

<< File: ical_45823.ics >>  << File: ATT00001.txt
>>