Martin, I think it's OK to use "deprecated". Since we're moving the standard over to OASIS it's in our best interest to make the transition as easy as possible.
Hence full backwards compatibility makes sense now and for the foreseeable future, but maybe some day when tooling is sufficiently robust and everybody has upgraded to v3+ we can talk about truly deprecating a feature that is currently only marked as such.
In the meantime clients can be developed against the non-deprecated specification, lessening the overall reliance on those features.
I am about to open up the ballot. Only members with voting privileges can vote on the ballot though all members will be able to see the results. If I've set
it up properly each question on the ballot will allow for a comment - including for example on what it really means to "prefer" a representation. The system does allow amendments to be added to the text but most likely we'll just set up a new ballot if we
needed. I can declare the ballot passed or rejected once we have quorum one way or the other.
Martin Sarabura
R&D Fellow, PTC
From: [mailto:]
On Behalf Of Martin P Pain
Sent: July-29-15 11:45 AM
To: Jim Amsden
Cc: OASIS
Subject: Re: [oslc-core] Resource Preview Proposal
In general I'm happy to go this way, but I do (as always) have some more thoughts. Apologies if I'm just nit-picking.
"deprecated":
What does it mean in this context to mark things as "deprecated" if we've said that we never want to break backwards compatibility? It seems to mean something that we would remove if we could but
we've said we're not going to.
1. Preview discovery:
a. Can I suggest that we change the rel from "...#Compact" to be "...#compact" (lower-case "c"). It seems wrong to use something that looks like a class name as a rel value. Following the convention
for triple predicates of a lower-case initial seems more fitting.
b. Saying "servers MUST honour" a Prefer header seems to go against the meaning of "Prefer" (e.g. vs "Expect" - although I don't know much about that header and I'm not suggesting we use it). Does
LDP require servers to honour any prefer headers that it specifies?
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Phone: +44 (0)1962 815317
| Tie-Line: 37245317
E-mail:
Find me on:
and
within IBM on:
IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
From: "Jim Amsden" <>
To: OASIS <>
Date: 29/07/2015 14:55
Subject: Re: [oslc-core] Resource Preview Proposal
Sent by: <>
After reviewing all the issues and options, which are discussed in detail in
https://wiki.oasis-open.org/oslc-core/V2Compatibility#preview,
I'd like to make the following simple proposal for Resource Preview:
1. Preview Discovery
To preserve compatibility with OSLC2, preview discovery must continue to support the Accept: application/x-oslc-compact+xml header to get the Compact resource. This usage will be noted as deprecated. OLSC3 clients should use the Link header with rel="http://open-services.net/ns/core#Compact"
and the Prefer header with include="http://open-services.net/ns/core#PreferCompact”, using the Accept header with standard MIME types such as text/turtle, application/rdf+xml, application/ld+json,
etc. to get the Compact resource in the desired format.
2. Preview Resource Representation
OSLC3 must continue to support the OSLC2 Compact resource XML representation. This format will be noted as deprecated. OSLC3 clients should use the Accept and Prefer headers to get the compact resource in Turtle or JSON format. Servers may support other formats
such as application/rdf+xml and application/ld+json.
3. Preview Resize
OSLC3 will continue to support the OSLC2 oslc-preview-height resize message, but this usage will be noted as deprecated. OSLC3 servers should use the oslc-resize message. OSLC3 servers should send both the oslc-preview-height and oslc-resize messages if OSLC2
compatibility is a requirement.
This results in very few changes to Resource Preview - just including the x- MIME type and XML format for the OSLC2 Compact resource, and handling the oslc-preview-height resize message for OSLC2 compatibility.
In order to complete the edits as soon as possible, we can try an electronic vote on this proposal.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
