Re: [oslc-core] Resource Preview issues

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

My counter-proposal would be to go with:

• application/x-oslc-compact+xml - OSLC 2.0 specific XML format
• application/x-oslc-compact-turtle - Turtle
• application/x-oslc-compact-rdf+xml - RDF/XML
• application/x-oslc-compact+json - JSON
• application/x-oslc-compact-ld+json - JSON-LD

(note the "-" in
place of "+" to keep us to just using the registered suffixes).

RFC6838 §4.2.8 doesn't say anything about
the meaning of removing a suffix from a media type, and I see no meaning
in doing so. So the difference between your proposal and this approach
would be whether to be consistent with the registered suffixes, or to be
consistent in what is before the suffix. I see slightly more value in the
former.

I think this is ready for a TC vote to decide
on which approach to take.
Perhaps we could first vote on moving away
from Prefer back to just media types, taking your ones as the draft ones
to use. Then vote on whether to change to my ones.

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:  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:      
 "Jim Amsden"
<jamsden@us.ibm.com>
To:      
 OASIS (oslc-core@lists.oasis-open.org)
<oslc-core@lists.oasis-open.org>
Date:      
 27/07/2015 19:00
Subject:    
   Re: [oslc-core]
Resource Preview issues
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Martin,

1. https://tools.ietf.org/html/rfc6838#page-12:probably
doesn't apply to x- unregistered or experimental MIME types. Of the underlying
structural syntaxes of the application/x-oslc-compact MIME type and subtype,
XML and JSON suffixes are registered, but RDF/XML, JSON-LD and Turtle are
not. 

The registered Media Types (http://www.iana.org/assignments/media-types/media-types.xhtml)
seem a bit inconsistent in this regard. application/rdf+xml and application/ld+json
are defined, but this does not recognize the fact that an RDF or Linked-Date
resource can have many other standard formats including Turtle and JSON.
 For example, LDP uses text/turtle and application/ld+json to reference
different representations of the same resource. It would seem that application/ld+turtle
would be more consistent. And what's the semantic difference between application/rdf
and application/ld (ignoring their suffixes)? These MIME types aren't actually
even defined.

I suggest we don't worry too much about this given that the OSLC MIME types
aren't registered and are likely never going to be registered since they
are already used in existing standards.

2. So I suggest we include the following Compact resource representations
in the Accept header:

• application/x-oslc-compact+xml - OSLC 2.0 specific XML format
• application/x-oslc-compact+turtle - Turtle
• application/x-oslc-compact+rdf+xml - RDF/XML
• application/x-oslc-compact+json - JSON
• application/x-oslc-compact+ld+json - JSON-LD

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:        OASIS
(oslc-core@lists.oasis-open.org) <oslc-core@lists.oasis-open.org>
Date:        07/24/2015
06:02 AM
Subject:        Re:
[oslc-core] Resource Preview issues
Sent by:        <oslc-core@lists.oasis-open.org>

---

https://tools.ietf.org/html/rfc6838#page-12:
"+suffix" constructs for as-yet unregistered
 structured syntaxes SHOULD NOT be used, given the possibility of
 conflicts with future suffix definitions.

These are the registered suffixes: 
http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
I think the only ones we are interested in are "+xml" and "+json".
That doesn't give us the full range that we might want to support.

Options: 
1.        Only specify the existing plain XML (RDF/XML
subset) and a new plain JSON (JSON-LD subset), as "+xml" and
"+json" respectively. Or:
2.        In addition to "application/x-oslc-compact+xml"
and "+json" for the plain formats, use something like "application/x-oslc-compact-rdf+xml"
and "+json" for the full syntax of RDF/XML and JSON-LD. Not sure
about tutrle, maybe "application/x-oslc-compact-turtle" or just
"application/x-oslc-compact-rdf".

I suggest option 1. Lower burden on servers (as IIRC they MUST support
the XML subset anyway), and fewer media types. Unfortunately it doesn't
allow clients to get the compact resource in Turtle.

(An unofficial workaround [hack] if a server wanted to make a Turlte representation
available could be for a HEAD or OPTIONS response to an "Accept: application/x-oslc-compact+xml"
or "+json" request could return a Content-Location header, and
a request on the URI provided by that header with an Accept:text/turtle
header could return a turtle representation of the compact resource, but
I won't suggest for a second that we standardize that.)

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:  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:        "Jim
Amsden" <jamsden@us.ibm.com> 
To:        OASIS
(oslc-core@lists.oasis-open.org) <oslc-core@lists.oasis-open.org>
Date:        23/07/2015
22:24 
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:  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:        "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 representation they 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