Re: [oslc-domains] OSLC RM Domain specs

["Nicholas Crossley" <nick_crossley@us.ibm.com>]

We discussed this before in the context
of Core 3.0, or parts thereof.

The thinking was this:

1. We do want new implementations to support Turtle, so we want to make that a MUST.
2. We would like to move away from RDF/XML because it's really difficult to read, and because we don't want to burden new implementations with unnecessary representations, so we make that optional.
3. Servers that feel compatibility with OSLC 2.0 is important are welcome to provide RDF/XML - the standard allows it.

So technically yes, it's an incompatible
change - but that incompatibility is the choice of the server, so we felt
it was OK.

For version numbering, we can't call
it 2.0, because there are some differences. I thought we had agreed on
2.1 or 2.0.1 or something?

Nick.



From:      
 Jad El-Khoury <jad@kth.se>
To:      
 Jim Amsden <jamsden@us.ibm.com>,
"Schulte, Mark D" <mark.d.schulte@boeing.com>, "oslc-domains@lists.oasis-open.org"
<oslc-domains@lists.oasis-open.org>
Date:      
 11/15/2017 03:36 AM
Subject:    
   [oslc-domains]
OSLC RM Domain specs
Sent by:    
   <oslc-domains@lists.oasis-open.org>

---

Hi,
 
I raised the issue of RM 2.0 compatibility
with OSLCCore3.0, and here’s an example (I think I earlier found another
example, but let’s first test if I understood compatibility correct):
 
OSLC Core 3.0, states that OSLC Services
MUST provide and accept text/turtle
http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part1-overview/oslc-core-v3.0-cs01-part1-overview.html#resourceRepresentations
 
RM 2.0 only requires MUST for RDF/XML representations.
 
Now, if we state that RM 2.0 specification
is based on OSLCCore3.0, does that not create a backward compatibility
issues for RM2.0? Existing RM 2.0 implementations have not necessarily
supported turtle.
 
Also, note that I have also just committed
some new changes to the RM Specs.
 
I earlier called the specs 3.0, but now
I understand we should stick to 2.0. So, I now renamed it 2.0.
This also meant I have reverted changes
to the following sections to be almost the same text as that under open-services:
* 2.2 Specification Versioning
* Appendix A. Version Compatibility with
2.0 Specifications
 
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