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-core] Resource Preview Proposal

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: oslc-core@lists.oasis-open.org [mailto:oslc-core@lists.oasis-open.org] On Behalf Of Martin P Pain
Sent: July-29-15 11:45 AM
To: Jim Amsden
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.

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
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 


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" <jamsden@us.ibm.com>
To:        OASIS <oslc-core@lists.oasis-open.org>
Date:        29/07/2015 14:55
Subject:        Re: [oslc-core] Resource Preview Proposal
Sent by:        <oslc-core@lists.oasis-open.org>

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


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

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