I see it the same way as Ian.
Going back to Martin's question:
> 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?
I don't see it significantly more complex
for a server to support both the legacy x-oslc-... media type and an additional
Prefer header with a standard media type specified in the Accept header.
In fact, I would recommend that we specifically deprecate the x-oslc-...
media type in order to encourage new servers and clients to begin supporting
OSLC 3.
And, I do believe that this will simplify
how a client has to process the request and the response. As Ian
said, the client will be able to use standard mechanisms (using Content-Type
header) for standard media-types to de-serialize the response.
Sincerely,
___________________________________________________________________________
Samit Mehta
Business Development, ISV Enablement
IBM Continuous Engineering, IBM Internet of Things
(512) 788-1458 - Mobile
mailto:
Ian Green1 <> wrote on 07/28/2015
11:14:34 AM:
> From: Ian Green1 <>
> To: Nick Crossley/Irvine/IBM@IBMUS
> Cc: Martin P Pain <>,
Samit Mehta/San
> Francisco/IBM@IBMUS, Jim Amsden/Raleigh/IBM@IBMUS, oslc-
>
> Date: 07/28/2015 11:14 AM
> 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 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
