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: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
- Date: Mon, 10 Aug 2015 08:25:01 -0400
OK, I think Nick is suggesting the right
direction. Favoring open-world assumptions, we should encourage servers
to send what they feel is appropriate and clients to ignore what they don't
need. Regarding non-RDF resources, a Prefer header asking for the CompactResource
in this case couldn't send any properties of the resource (since its not
RDF). I suppose that wouldn't stop the server from sending additional metadata,
or synthesizing RDF properties, and that would be fine too. So the restriction
that Prefer can only be used on RDF sources doesn't appear to be necessary.
The rest is fine.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
Nick Crossley/Irvine/IBM@IBMUS
To:
Jim Amsden/Raleigh/IBM@IBMUS
Cc:
Martin P Pain <martinpain@uk.ibm.com>,
"OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:
08/06/2015 04:29 PM
Subject:
Re: [oslc-core]
Compact resource and the Prefer header
Sent by:
<oslc-core@lists.oasis-open.org>
I'm not sure I see a problem here. A
server is at liberty to add any of the properties of the resource to its
compact resource - the spec states:
All elements MAY have additional attributes
not specified here. All elements, other than dcterms:title and oslc:shortTitle,
MAY include additional child elements not specified here. Consumers MUST
quietly ignore unknown elements and attributes encountered in a Compact
representation.So a 2.0 server MAY include in a compact
resource none, some, or all of the properties that it would return in the
standard representation. With 3.0-style Prefer headers, a server MAY honor
other Prefer headers to allow the client to request an appropriate set
of those properties. The only question is whether or not it's worth defining
some prefer headers to specify particular sets (such as a preference for
the full set of all standard properties plus the compact ones). Personally,
I don't believe this is the case.
Nick.
Jim
Amsden---08/06/2015 12:51:10 PM---Martin, Just a few additional points...
From: Jim Amsden/Raleigh/IBM@IBMUS
To: Martin P Pain <martinpain@uk.ibm.com>
Cc: "OASIS OSLC Core TC Discussion
List" <oslc-core@lists.oasis-open.org>
Date: 08/06/2015 12:51 PM
Subject: Re: [oslc-core] Compact
resource and the Prefer header
Sent by: <oslc-core@lists.oasis-open.org>
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]