Re: [oslc-core] Resource Preview issues

[Martin P Pain <martinpain@uk.ibm.com>]

I agree Prefer would be the correct way
to go if we were starting from scratch.

The question is: is it a good idea to
say that servers MUST support application/x-oslc-compact+xml and MUST support
the Prefer header.

There's a risk that it'll encourage
non-compliant implementations as the chance is that their first target
client will only require one or the other of them. (I think that's one
of the things we mean when we're talking about "reducing the burden
on server implementations" - aside from putting people off of OSLC
altogether). Whereas if we just used the Content-Type header at least it's
doing things in the same way.

I don't know which is the best way to
go. But I do think it's a balancing act - that it's not clear one way or
the other. There's always the chance implementations will be non-conformant
whatever we do, and in large part that's the implementors' responsibility
not ours, but we can make their lives easier or harder. I believe using
a Prefer header is making their life slightly harder, but perhaps only
to a small degree and so maybe it's worth it to have a slightly cleaner/more
modern spec, i.e. "We use the Prefer header, but servers MUST also
support application/x-oslc-compact+xml for backwards-compatibility".

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:      
 Ian Green1/UK/IBM
To:      
 Nick Crossley <ncrossley@us.ibm.com>
Cc:      
 Martin P Pain/UK/IBM@IBMGB,
Samit Mehta <samit.mehta@us.ibm.com>, Jim Amsden <jamsden@us.ibm.com>,
oslc-core@lists.oasis-open.org
Date:      
 28/07/2015 17:14
Subject:    
   Re: [oslc-core]
Resource Preview issues

---

It is undesirable to introduce additional
media types (registered or not) rather than using Prefer header.  I
see application/x-oslc-compact+xml  as
being used only for backwards compatibility.  Quoting Jim:

> Given that, it seem like the simplest
and most straight forward solution is to hold our noses and start cluttering
the media type space as needed. 

Those x- media types are not "new"
media types - calling them such makes clients have to understand the semantics
(read the specs) only to find "ahh its just RDF".  The Prefer
header allows us to avoid digging that x- hole any deeper.  Isn't
that one of the use cases for Prefer?

best wishes,
    -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational

<oslc-core@lists.oasis-open.org> wrote on 24/07/2015
18:54:47:

> From: Nick Crossley <ncrossley@us.ibm.com>
> To: Martin P Pain/UK/IBM@IBMGB
> Cc: Samit Mehta <samit.mehta@us.ibm.com>,
Jim Amsden 
> <jamsden@us.ibm.com>, OASIS (oslc-core@lists.oasis-open.org)
<oslc-
> core@lists.oasis-open.org>
> Date: 24/07/2015 18:55
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> I would prefer that Core 3.0 has some way to ask for the compact 
> resource in Turtle and JSON-LD as well as the 2.0 compatible XML.
 I
> do not have a very strong opinion on which is the better way to do
> that - add options to a Prefer header or add unregistered media 
> types.  Or even ask for new registered media types.
> 
> Nick.
> 
> 
> [image removed] Martin P Pain ---07/24/2015 08:29:49 AM---Thanks for
> your input Samit. This is where we were thinking about using the 
> "Prefer" header, but the
> 
> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Samit Mehta/San Francisco/IBM@IBMUS
> Cc: Jim Amsden/Raleigh/IBM@IBMUS, OASIS (oslc-core@lists.oasis-
> open.org) <oslc-core@lists.oasis-open.org>
> Date: 07/24/2015 08:29 AM
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Thanks for your input Samit. 
> 
> This is where we were thinking about using the "Prefer"
header, but 
> then decided not to do that because we need to continue to support
> the old content type and there's no point in having two ways to do
it. 
> 
> However, now we're considering having multiple formats of compact
> representation (XML, JSON, full JSON-LD, Turtle) that makes it more
> complicated, so going back to the Prefer header (while keeping the
> old content type as a special case) is one option. 
> 
> However I suggest (as stated in my recent email) we just stick with
> two formats: plain XML (RDF/XML subset) and plain JSON (JSON-LD 
> subset) with "+xml" and "+json" content types,
respectively. This 
> avoids the complexity of having two different ways of requesting the
> compact representation (Accept and Prefer headers), but has the 
> downside of not supporting Turtle. 
> 
> Samit, what's your view on the downsides of server implementors 
> having to support the legacy content type in addition to some other
> header? It sounds like you don't think it would be a problem, is 
> that correct? 

> 
> 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: [image removed]  and within IBM on: [image removed]
  
> 
> [image removed] 
> 
> 
> 
> 
> IBM United Kingdom Limited Registered in England and Wales with 
> number 741598 Registered office: PO Box 41, North Harbour, 
> Portsmouth, Hants. PO6 3AU 
> 
> 
> 
> From:        "Samit Mehta" <samit.mehta@us.ibm.com>
> To:        "Jim Amsden" <jamsden@us.ibm.com>
> Cc:        OASIS (oslc-core@lists.oasis-open.org)
<oslc-
> core@lists.oasis-open.org> 
> Date:        24/07/2015 15:42 
> Subject:        Re: [oslc-core] Resource Preview
issues 
> Sent by:        <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Continuing to support application/x-oslc-compact+xml for backward
> compatibility is essential.
> 
> For OSLC3, could we use a combination of Accept and some other 
> Accept header (such as Accept-Encoding) to support requesting the
> compact representation. Accept header can be used to specify a 
> standard media type, and the other Accept header can specify "oslc-
> compact". This is assuming that there is a separate Accept header
> that can be used without violating the HTTP spec.
> ___________________________________________________________________________
> Samit Mehta
> Business Development, IBM Continuous Engineering, IBM Internet of
Things
> 
> 
> 
> [image removed] Jim Amsden---07/23/2015 04:24:32 PM---Hummm... OSLC
> Core 2.0 uses an unregistered, experimental media type to access the
> 
> From: Jim Amsden/Raleigh/IBM@IBMUS
> To: OASIS (oslc-core@lists.oasis-open.org) <oslc-core@lists.oasis-open.org>
> Date: 07/23/2015 04:24 PM
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Hummm...
> 
> OSLC Core 2.0 uses an unregistered, experimental media type to 
> access the Compat resource: application/x-oslc-compact+xml. RFC 4288
> discourages this, but indicates they are ok for use only with the
> active agreement of the parties exchanging them - that certainly 
> applies to an OASIS Standard. 
> 
> Given that these are unregistered, we could easily create other 
> variants for application/x-oslc-compact+turtle, application/x-oslc-
> compact+xml+rdf, application/x-oslc-compact+ld-json, etc. As Martin
> suggests, that feels like contributing to a bad practice. But even
> if we decided to retain the OSLC3 Link and Prefer header approach
to
> Preview discovery, we'd stll need to support Accept: application/x-
> oslc-compact+xml for backward compatibility. Given that, it seem 
> like the simplest and most straight forward solution is to hold our
> noses and start cluttering the media type space as needed.
> 
> 
> 
> 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: 
> Date: 07/23/2015 12:20 PM
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> 
> 
> See response inline below 
> 
> 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: [image removed] and within IBM on: [image removed] 
> 
> [image removed] 
> 
> 
> 
> 
> 
> 
> 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) <oslc-core@lists.oasis-open.org>
> Date: 22/07/2015 20:37 
> Subject: [oslc-core] Resource Preview issues 
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Resource Preview 2.0 compatibility raises a few issues, hopefully
a 
> small enough number to be able to address in a single email.
> 
> 1. Preview Discovery
> 
> OSLC2 does Preview Discovery via GET on a resource that supports 
> Preview using an Accept: application/x-oslc-compact+xml header to
> request the Compact resource representation of the resource.
> 
> OSLC3 uses HEAD or OPTIONS on the resource and gets the URI for the
> Preview from a Link header. This takes two HTTP requests. Clients
> can get the Compact resource in one step by using the Prefer: 
> return=representation; include="http://open-services.net/ns/core#PreferCompact
> " header on the GET to get the Compact resource in a single request.
> 
> Discussion: The OSLC2 application/x-oslc-compact+xml header would
be
> a third way to get the Compact resource. Should all three be 
> supported, or is the OSLC2 approach actually the simplest and most
> HTTP consistent? 
> 
> Resolution: I think OSLC2 got this right and OSLC3 preview discovery
> is unnecessarily complex. Accept headers are used to negotiate 
> resource representations, and a Compact resource is an indirect 
> representation of a resource for display purposes. So I recommend
> continuing to use the Accept: application/x-oslc-compact+xml to get
> the Compact resource, and eliminate the OSLC3 Link and Prefer headers.
> 
> MP: Covered in the meeting.
> 
> 
> 2. Compact Resource Representation
> 
> Compact resource is an XML document in OSLC2, although it may be 
> RDF/XML it should be processed as XML. This format will also need
to
> be supported and return when the media-type requested through the
> Accept header is application/x-oslc-compact+xml. 
> 
> OSLC3 Compact resource representation MUST be application/json and
> text/turtle, SHOULD be application/ld+json.
> 
> Resolution: add OSLC3 Compact resource MUST support media-type 
> application/x-oslc-compact+xml in addition to the JSON and RDF 
> representations. Clients use Accept header to get the representationthey
want.
> 
> MP: OSLC 3 servers need to return the same subset of RDF/XML as 
> defined by v2 unless the client explicitly asks otherwise. For v2
> cients to be abe to work with v3 servers. SI that what you're saying?
> MP: They can't use the request header to request JSON or Turtle, as
> the content-type is already being used to select that we want the
> compact representation(/resource) rather than the regular 
> representation(/resource). We could have a "+json" equivalent,
which
> would probably be a json-ld-compatible specific subset of JSON 
> (which I think we might have already been talking about in the 
> Prefer: and Link: header ideas for preview discovery?). But I don't
> expect "+turtle" would be valid or a good idea. 
> MP: It looks like neither "application/json" nor "text/turtle"
> officially support a "profile" parameter. If they did, we
could have
> used the existing content type for XML, and then used the "profile"
> parameter on those two for JSON & Turtle. But we can't...
> MP: My suggestion is to leave the existing one as is (as we agree
ni
> the meeting today) and also define a "+json" equivalent.
Feels like 
> doing more of a bad thing, but it seems the best approach to me 
> given where we are right now.
> 
> 3. Preview Resize message
> 
> OSLC2 resize message is "oslc-preview-height: <newHeight>"
> 
> OSLC3 resize message is oslc-resize: {"oslc:hintHeight":
> <newHeight>, "oslc:hintWidth": <newWidth>}
> 
> Resolution: OSLC3 supports 2 resize messages, one for just height
> that would work with 2.0 clients, and one that includes height and
> width in the oslc-resize message. OSLC 3.0 clients would look for
> both. OSLC3 servers should send just the height message or both if
> there is a reason to send height and width information. 
> 
> MP: Agreed. I think it's important to say that servers should send
> both "oslc-preview-height" and "oslc-resize" messages
if setting the
> width. Just saying "both" might be intepreted as "send
just oslc-
> resize, containing 'both' width and height". It's an unfortunate
> burden on servers, and one that I expect a number will not follow,
> but it seems that the only alternative is not allowing changing of
> width, which we want to do. (Or, saying that for previews you can
> only specify oslc:hintWidth in an oslc-resize message, and the 
> height always has to go through an oslc-preview-height message. That
> would avoid duplication.)
> 
> 
> 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


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