Re: [oslc-core] Resource Preview issues

[Ian Green1 <ian.green@uk.ibm.com>]

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