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

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
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 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


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]