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] JSON-LD of compact resources


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

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



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]