Re: [oslc-core] MUST honour Prefer header.Re: [oslc-core] Resource Preview Proposal

["Jim Amsden" <jamsden@us.ibm.com>]

No, that's what I understood. There are
lots of things in HTTP and LDP that are optional for servers, and it seems
OK for OSLC to make that stronger if needed, just like domains make OSLC
core optional features stronger if they need them.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Martin P Pain <martinpain@uk.ibm.com>
To:      
 Jim Amsden/Raleigh/IBM@IBMUS
Cc:      
 OASIS <oslc-core@lists.oasis-open.org>
Date:      
 07/30/2015 05:24 AM
Subject:    
   [oslc-core]
MUST honour Prefer header.Re: [oslc-core] Resource Preview Proposal
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

I think you misunderstood what I was
trying to say in 1b. 

I was saying that m

The definition of the Prefer header in RFC 7240 (§2) says:

The Prefer request header field is used to indicate that particular
  server behaviors are preferred by the client but are not required
for
  successful completion of the request.  Prefer is similar in
nature to
  the Expect header field defined by Section
6.1.2 of [RFC7231] with
  the exception that servers are allowed to ignore stated preferences.

The intention of Prefer headers, according to that RFC, is that "servers
are allowed to ignore stated preferences". Saying that OSLC servers
MUST honour a particular Prefer header seem to be going somewhat against
that intention. (Although not entirely, as it is not the client that is
forcing the server to honout it, but our spec...) 

Does anyone else have an opinion on this?

Kind regards,

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

Phone:+44 (0)1962 815317 | Tie-Line:37245317 E-mail: martinpain@uk.ibm.com 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" <jamsden@us.ibm.com> 
To:        OASIS
<oslc-core@lists.oasis-open.org> 
Date:        29/07/2015
18:11 
Subject:        Re:
[oslc-core] Resource Preview Proposal 
Sent by:        <oslc-core@lists.oasis-open.org>

---

Martin:

1.a. I don's see an issue with change #Compact to #compact, after all the
rel is reference an instance of Compact, not the class itself. However,
there are other cases of this in resource preview and delegated dialogs.
They should be handled consistently.

Anyone have an issue with that or know of a reason #Compact was used? Is
this something we want to do consistently?

1.b. In the spirit of OSLC domain specifications and their relationship
to Core, it seems reasonable for OSLC Core to specify what optional parts
of LDP or HTTP are MUST from its standpoint. This seems OK to me.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:        Martin
P Pain <martinpain@uk.ibm.com>
To:        Jim
Amsden/Raleigh/IBM@IBMUS
Cc:        OASIS
<oslc-core@lists.oasis-open.org>
Date:        07/29/2015
12:21 PM
Subject:        Re:
[oslc-core] Resource Preview Proposal
Sent by:        <oslc-core@lists.oasis-open.org>

---

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: martinpain@uk.ibm.com 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" <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
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



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