OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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" <mark.d.schulte@boeing.com>
To:        Jad El-Khoury <jad@kth.se>, Jim Amsden <jamsden@us.ibm.com>
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:jad@kth.se]
Sent:
Friday, October 27, 2017 5:19 PM
To:
Jim Amsden <jamsden@us.ibm.com>
Cc:
Schulte, Mark D <mark.d.schulte@boeing.com>
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
jad@kth.se, www.kth.se
 
From: Jim Amsden [mailto:jamsden@us.ibm.com]
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 <jad@kth.se>
To:        
"Schulte, Mark D" <mark.d.schulte@boeing.com>, Jim Amsden <jamsden@us.ibm.com>
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

jad@kth.se, www.kth.se

From:
Schulte, Mark D [
mailto:mark.d.schulte@boeing.com]
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:
workgroup_mailer@lists.oasis-open.org[mailto:workgroup_mailer@lists.oasis-open.org]
Sent:
Monday, October 02, 2017 1:48 PM
To:
workgroup_mailer@lists.oasis-open.org; oslc-domains@lists.oasis-open.org
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 >>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]