oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Compact resource and the Prefer header
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: Martin P Pain <martinpain@uk.ibm.com>
- Date: Thu, 6 Aug 2015 15:50:46 -0400
Martin,
Just a few additional points...
1. Would clients typically want to get
a resource (in whole or part) and the Compact Resource at the same time?
Aren't these relatively distinct operations? If a client wants to simply
display the link with an icon and label, they only need the compact resource.
If they want the service provider to display a UI for the link, then that's
also available from the compact resource small and large dialog. If they
need more than that, then they would GET the resource and usually display
it themselves in their own purposeful UI.
Is there a common need to get both the
resource and its compact representation in the same request? Is this being
supported simply because it is typical behavior for a server's response
to a Prefer header?
2. I can see how the compact resource
can be embedded in any RDF request response body in a standard accessible
way. But:
2.1. This would only work on RDF-Source
which would limit the ability to use the Prefer header to get the compact
resource in one request for non-RDF resources.
2.2. How would clients deal with unpredictable
resource content? Requiring servers to return all or none wouldn't seem
that useful or predictable.
I think the root of the problem here
is that we are attempting to use the Prefer header with return=representation
as a loose form of content negotiation.
The best solution may to simply have
the Prefer header to that and only return the compact resource, and not
embed it in an unspecified, unpredictable part of, or even the whole resource.
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
TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date:
08/06/2015 06:21 AM
Subject:
Re: [oslc-core]
Compact resource and the Prefer header
Sent by:
<oslc-core@lists.oasis-open.org>
If we can have a consistent & standardised
way to embed the compact resource in the specification, then I suggest
that we should allow servers to include some or all of the target resource
as well as the compact resource. This allows a client and a server from
the same vendor to optimise a request for both into one request. Clients
would need to be able to fall back to sending two requests (one for the
main representation, one for the compact resource) if communicating with
a server that is from a different vendor. How would they know if the response
contained all or part of the target resource? Erm... good question. OK,
I don't have an answer for that one that doesn't add complexity. Only that
the client can see whether it includes the particular properties that is
of interest to it, if it knows what their predicates are in advance.
To avoid that problem, we could say that the server MAY include all the
properties that it would have done without that Prefer header or it MAY
return none of them (just the compact resource), but it MUST NOT return
a subset. This would obviously be a significant change from what it says
now, and I'm not sure it's a restriction that we want.
I expect we do have a way to consistent & standardised way to
embed the compact resource within a representation of the target resource.
For JSON, under section
5.1.2 we say that it must
be under a property called "compact" on the top-level object.
And for any RDF languages, we provide the URI for the compact resource
in a Link header so the compact resource's properties will be the triples
with that URI as the subject. We don't say whether the responses to the
Prefer header requests should contain the link header or not. I suggest
we should do, as I would expect that should be the subject of triples about
the compact resource, whichever method the client uses.
Martin
Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel |
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 TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date: 05/08/2015
20:09
Subject: [oslc-core]
Compact resource and the Prefer header
Sent by: <oslc-core@lists.oasis-open.org>
The OSLC 3 resource preview specification indicates the MUST honor a client's
request using the Prefer header to in-line a Compact Resource in JSON and
RDF representations.
It also says the servers MAY choose to return only a subset of the target
resource properties when the compact resource is in-lined. Note a consequence
of this is that the Prefer header can only be used to get the compact resource
representation in one request if the resource itself is an RDF resource.
This seems like an unfortunate and unnecessary restriction.
Why would the Prefer: return=representation; include="http://open-services.net/ns/core#PreferCompact"
return some unspecified part of the target resource with the Compact Representation
embedded in it in some unspecified way? Is there a scenario/use case that
describes when a client would want some partial representation of a resource
and its compact representation in the same request?
Should we simplify this and just have the Prefer header return the compact
resource representation and avoid embedding it in some unspecified subset
of the target resource?
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]