OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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


Phone:+44 (0)1962 815317 | Tie-Line:37245317
E-mail:
martinpain@uk.ibm.com
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 
IBM




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]