Hi Jim,
I agree with the argument below. (I always wonder why people can passionately argue for one format over the other. I guess I need to do more programming.)
Anyway, the suggested change below applies to the Core 3.0 specs, right?
For the [RM] specs, should we also then change the following (section 2.4) from MUST to SHOULD?
RM Servers MUST support RDF/XML representations ...
RM Servers MUST support XML representations ....
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: oslc-core@lists.oasis-open.org [mailto:oslc-core@lists.oasis-open.org]
On Behalf Of Jim Amsden
Sent: 07 December 2017 18:49
To: OASIS OSLC Core TC Discussion List
Subject: [oslc-core] Re: FW: [oslc-domains] OSLC RM Domain specs
Jad,
We may have gotten this wrong, same as with OSLC Core 2.0 and LDP paging. First, the actual RDF serialization format is not something that OSLC should even need to address. OSLC should only specify
that the resources are represented as any standard RDF format. The reason is that no OSLC client should ever depend on a specific resource serialization representation, and they should utilize RDF parsers that support any standard representation. Otherwise
interoperability suffers.
Now unfortunately this is not the case. Some tools rely on RDF/XML with inlined resources, even going so far as to expect the results to be in RDF/XML-ABBREV, something that isn't even a standard.
These clients may use XPath or other lexical mechanisms to "parse" these RDF/XML files for their convenience, and to avoid using RDF parsers. So we have to deal with this.
For OSLC, interoperability with 2.0 clients and servers is more important than whether RDF/XML, Turtle or JSON-LD is the serialization format. Since we know there are implementations that are limited
to RDF/XML, then we should continue to support that in OSLC 3.0 and the domain specifications.
I would prefer to change all these to SHOULD, and to document in the clause why - SHOULD support Turtle and JSON-LD because they are simpler, more readable representations mandated by LDP. SHOULD
support RDF/XML because it is required by OSLC 2.0 and there are many existing clients and servers you might want to integrate with.
Now what the servers provide is not over specified and left to what they need to provide in their broader execution environment.
See https://issues.oasis-open.org/browse/OSLCCORE-142
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Jad El-Khoury <jad@kth.se>
To: Jim Amsden <jamsden@us.ibm.com>, Andrii Berezovskyi <andriib@kth.se>
Date: 12/07/2017 11:02 AM
Subject: FW: [oslc-domains] OSLC RM Domain specs
The argument to requiring Turtle in Core 3.0
______________________________
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: 15 November 2017 20:25
To: Jad El-Khoury
Cc: Jim Amsden; Schulte, Mark D;
oslc-domains@lists.oasis-open.org
Subject: Re: [oslc-domains] OSLC RM Domain specs
We discussed this before in the context of Core 3.0, or parts thereof.
The thinking was this:
-
We do want new implementations to support Turtle, so we want to make that a MUST.
-
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.
-
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