oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] JSON-LD of compact resources
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: John Arwe <johnarwe@us.ibm.com>
- Date: Thu, 1 May 2014 15:06:47 +0100
I agree with you on the 200 vs 209/3xx
Regarding media types, I don't think
we need the Profile (although that doesn't mean we can't use it). If the
consumer found the URI in a Link header with the appropriate "compact"
rel, then that should be enough to set up the _expectation_ of a representation
of a compact resource, in whatever media type is requested (e.g. JSON,
JSON-LD, RDF/XML, Turtle). The provider might return something that is
not compatible with compact resources, as always with expectations set
by rel or predicates, in which case the consumer just won't know what to
do with it.
I don't think we'd need an explicit
way for the consumer to be able to detect whether or not it is a compact
resource (e.g. the Profile header) - it has had the expectation set by
how it found the URI, and if what it receives is compatible with that then
it uses it as a compact resource. If it's not, it can't. I think the case
where the provider returns a JSON representation that looks like a compact
resource - but isn't - is practically zero.
(This is one thing I tried to communicate
in my previous emails)
Does anyone disagree?
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee chair
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
<oslc-core@lists.oasis-open.org> wrote on 01/05/2014
14:42:25:
> From: John Arwe <johnarwe@us.ibm.com>
> To: oslc-core@lists.oasis-open.org,
> Date: 01/05/2014 14:42
> Subject: Re: [oslc-core] JSON-LD of compact resources
> Sent by: <oslc-core@lists.oasis-open.org>
>
> This draft is confused/ing.
> 1: R vs C(R)
> If I have a resource identified by the URI R,
and it has a
> corresponding core:Compact resource identified by the URI C(R), then
> there is just no way that "GET R" should *ever* be returning
the
> representation of C(R) and status code 200, which section 5.1
> allows. 209 or 3xx, fine.
> It's debatable (since R != C(R) ) whether or
not the "Prefer
> compact" approach is even within the envelope of what Prefer
is for:
> "The Prefer request header field is used to indicate that particular
> server behaviors are preferred by the client, but not required for
> successful completion of the request." If the client requests
a
> representation of R, and (via prefer compact) the intent is that it
> receives another resource entirely (C(R), versus some different
> subset of the state of the resource identified by the request-URI,
> i.e. R), *at the HTTP level* only the draft 209 status code or the
> existing 3xx codes allow returning C(R).
> I think you would be within all the specs if
it was written differently, e.g.
> If 209 (or 3xx)
> - Must preference-applied, Must Location, response
body must be a
> representation of C(R)
> If 200
> - Must provide link header corresponding to the
triple R, compact, C(R)
> Once you state that R and C(R) are different
resources, you lose any
> claim to be able to say that GET R returns 200 and representation
C
> (R), *regardless* of preferences. This is different from the
RFC's
> return=representation cases where HTTP says that "a" representation
> [of something] is returned, and the preference expresses [of what]
> ... e.g. 201 responses. The [of what] for 200 is well-defined
in
> HTTP already, preferences don't get to rewrite that.
> 2: Media types
> If you use generic media types ... application/json,
application/ld
> +json ... then a server satisfies the media type contract by
> returning ANY valid JSON or JSON-LD, respectively. If the client
> expects it to have any specific content, it is outside the bounds
of
> the media type registration: the server asserted it's generic,
> nothing else. If you want the server to assert that it's YOUR
kind
> of JSON/LD, you need something more (profile response header seems
> to be the vogue in IETF, and would be usable here), or your own
> media type. I'm guessing in this case that the profile URI would
be
> the URI identifying a resource shape.... presumably the one in your
spec.
> ------------------
> As another alternative to 1, you might consider
RFC 6570. Let the
> server expose a URI template for its compact resource URIs. As
a
> Link header for the general case, and possibly as a core predicate
> for containers/their members to cover the common case where all the
> container's members have a common template (so one URI, whose
> content can be cached, just like we've discussed for slimming down
> JSON-LD representations generally).
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Tivoli OSLC Lead - Show me the Scenario
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]