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


Having just written a unit test for a "getCompact()" handler, I know that I would like it if the standard supported the serialization and marshalling of a Compact from JSON.

As it was, my test serialized the response to string, parsed it back to Xml Dom, and then investigated the accuracy of the structure with Xpath expressions. Working with JSON formats of the structure would have been handy.

Apparently to this tyro, me, a "Compact" is the analog of the "Catalog" where the latter describes the resource/service URLs for an Artifact Container and the former describes the resource/service URLs for a particular resource within the container.

On 4/11/14, 7:40, Samuel Padgett wrote:

Ian,

On discovering the Compact resource, I'm not sure we've made a decision. I plan to create a wiki page showing the three proposals. Briefly, here they are:

1) Custom media type a la OSLC 2.0 - application/oslc-compact+json
2) Link response header - Link: <http://example.com/bugs/4?compact>; rel="compact"
3) Prefer request header - Prefer: type=oslc-compact

How you discover the Compact resource might play into what media types we support.

I think we all agreed the Compact resource really is a different resource.

--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC


Inactive
          hide details for Ian Green1 ---04/08/2014 11:16:03 AM---Hi
          Martin I thought there had been agreement that "compact
          repIan Green1 ---04/08/2014 11:16:03 AM---Hi Martin I thought there had been agreement that "compact representation" would be


    From:

Ian Green1 <ian.green@uk.ibm.com>

    To:

Martin P Pain <martinpain@uk.ibm.com>

    Cc:

oslc-core@lists.oasis-open.org, John Arwe/Poughkeepsie/IBM@IBMUS

    Date:

04/08/2014 11:16 AM

    Subject:

Re: [oslc-core] JSON-LD of compact resources

    Sent by:

<oslc-core@lists.oasis-open.org>





Hi Martin 
I thought there had been agreement that "compact representation" would be a misnomer in v3.  Rather, there would be a resource C, (typically) distinct from R, whose representation(s) could be used to build a UI preview of R.  The minutes [1] echo this - are the minutes incorrect?
 

I see the current draft at [2] uses content negotiation to request the "compact representation".  Is the current draft ahead or behind the meeting decisions (or were these not decisions at all?)
 

[1]
https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.03.20 
[2]
http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/resource-preview.html 


best wishes,
  -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational
 

<oslc-core@lists.oasis-open.org> wrote on 07/04/2014 17:48:46:

> From: John Arwe <johnarwe@us.ibm.com>
 
> To: oslc-core@lists.oasis-open.org
 
> Date: 07/04/2014 17:48
 
> Subject: Re: [oslc-core] JSON-LD of compact resources
 
> Sent by: <oslc-core@lists.oasis-open.org>
 
>
> > 1. Somewhere the consumer gets the URL for the compact resource,
> > probably through
> >     following a link from another resource.
>
> I'm not sure what a "compact resource" is.  In the contributed
> specs, there is simply "a" resource and it either does/not have a
> compact *representation*.
> There have been past discussions to the effect that the "compact  
> representation" language is incorrect, and it *should be* a separate
> resource ... is that your meaning?  I thought on the call we agreed
> to stick with the base definitions, but maybe I missed something.
>
> > 2. It knows, through a specification it was implemented against
> > (i.e. a resource shape
> >     from that spec) that the target of that link is "likely to be" a
> > compact representation.
>
> The client only knows (sticking with contributed-specs language in
> this reply) that the resource identified by the URL it holds might/
> not have a compact representation.
> Even without that critical distinction, in general I'd be careful
> about implying anything around resource shapes; in our
> implementations it has been 1/n-1 (against resource shapes, i.e.
> exactly 1 product exposes them out of a dozen-plus).
> >    4ai)IF the resource really is a compact representation then it
>
> I think that's: If the server returned a compact representation ...
>
> Which raises a NEW question, if we have >1 compact representation:
> how does the client know if it got back a compact representation?  
> In the contributed document, there is only one media type that
> covers both "what it is" semantically and "what syntax does it use".
> On our espoused path that relation is no longer 1:1, and the media
> type only conveys the syntax (I assert, given what those media type
> registrations say).  
>
> (and flipping this around) If we allow these json media types *as a
> way for a client to ask for a compact representation*, how does the
> server know to send a *compact* representation, vs a JSON or JSON-LD
> serialization of what a client would receive on a text/turtle
> request to the same URL?  I.e. how does the server know (given that
> the URL for the "compact representation" and the not-compact one are
> the same) which the client is really after?
>
>


> 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



Attachment: signature.asc
Description: OpenPGP digital signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]