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 Green1/UK/IBM@IBMGB)
IBM Rational
<> wrote on 24/07/2015
18:54:47:
> From: Nick Crossley <>
> To: Martin P Pain/UK/IBM@IBMGB
> Cc: Samit Mehta <>,
Jim Amsden
> <>, OASIS ()
<oslc-
> >
> Date: 24/07/2015 18:55
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <>
>
> 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 <>
> To: Samit Mehta/San Francisco/IBM@IBMUS
> Cc: Jim Amsden/Raleigh/IBM@IBMUS, OASIS (-
> open.org) <>
> Date: 07/24/2015 08:29 AM
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <>
>
>
>
> 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:
> 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" <>
> To: "Jim Amsden" <>
> Cc: OASIS ()
<oslc-
> >
> Date: 24/07/2015 15:42
> Subject: Re: [oslc-core] Resource Preview
issues
> Sent by: <>
>
>
>
> 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 () <>
> Date: 07/23/2015 04:24 PM
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <>
>
>
>
> 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 <>
> To: Jim Amsden/Raleigh/IBM@IBMUS
> Cc:
> Date: 07/23/2015 12:20 PM
> Subject: Re: [oslc-core] Resource Preview issues
> Sent by: <>
>
>
>
> 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:
> 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" <>
> To: OASIS () <>
> Date: 22/07/2015 20:37
> Subject: [oslc-core] Resource Preview issues
> Sent by: <>
>
>
>
> 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
