Re: [oslc-core] Resource Preview issues

["Samit Mehta" <samit.mehta@us.ibm.com>]

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:samit.mehta@us.ibm.com


Ian Green1 <ian.green@uk.ibm.com> wrote on 07/28/2015
11:14:34 AM:

> From: Ian Green1 <ian.green@uk.ibm.com>
> To: Nick Crossley/Irvine/IBM@IBMUS
> Cc: Martin P Pain <martinpain@uk.ibm.com>,
Samit Mehta/San 
> Francisco/IBM@IBMUS, Jim Amsden/Raleigh/IBM@IBMUS, oslc-
> core@lists.oasis-open.org
> 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.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