Hi Boris, [ id1, id2, id3 ] +1 :) Jean Le samedi 18 janvier 2014 à 17:42 +0100, Boris Parak a écrit :
Hi Jean,
yep, you are right. The plain rendering has this:
||> It is RECOMMENDED to use the text/uri-list Accept HTTP header for this request.
but it's just a recommendation and the use of 'X-OCCI-Location' or 'Location' makes it self-contained without the use of text/uri-list.
So, we should probably do something similar for JSON as well. Both
{ entities: [ id1, id2 ] } (1) or { collection: [ id1, id2 ] } (2)
are acceptable. What about something even less complicated?
[ id1, id2, id3 ]
It's a valid JSON + no other message in OCCI JSON rendering contains an array directly + it basically the same as using Location or text/uri-list. Of course, IDs would actually be URIs (== locations).
Cheers, Boris
On Fri, Jan 17, 2014 at 1:08 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
Hi, IMO, each rendering should be self-contained, so my answer is yes :)
Jean
Le vendredi 17 janvier 2014 à 13:05 +0100, Boris Parak a écrit :
On Fri, Jan 17, 2014 at 11:21 AM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
If I understand correctly, a collection does not contain the detailed representation of resources, only their id, which can have huge consequences on implementation performances. That's why I was looking for a representation of a list of resources (or links) ids.
That's a good point. At the moment, we are rendering either "full" collections in JSON or using 'text/uri-list' in the request to get a list of IDs.
Basically, it may be: { entities: [ id1, id2 ] } (1) or { collection: [ id1, id2 ] } (2) or { resources: [ id1, id2 ], links: [ id3, id4 ] } (3) or { resources: [ { id: id1 }, { id: id2 } ], links: [ { id: id3 }, { id: id4 } ] } (4)
Any of these is fine for me, but I really think we should agree on a representation of collection without resources details. Order is my preference order.
You are right, it might be a good idea to address this in the document. Do we need a JSON-specific rendering for a collection of IDs when there is text/uri-list?
Any idea on this ? Jean
Boris
Le vendredi 17 janvier 2014 à 11:11 +0100, Boris Parak a écrit :
Yes :)
{ resources : [ RESOURCE1_JSON_HERE, RESOURCE2_JSON_HERE, RESOURCE3_JSON_HERE ] }
where RESOURCE*_JSON_HERE might look something like this:
{ "kind": "http://schemas.ogf.org/occi/infrastructure#compute", "mixins": [ "http://www.example.org/occi/my_scheme#my_term" ], "attributes": { "occi": { "core": { "id": "1f975fd3-71f7-43e2-bffd-9fdee3825b55", "title": "Cmpt1" } } }, "id": "1f975fd3-71f7-43e2-bffd-9fdee3825b55", "links": [ "/link/storagelink/b2d46a50-ad9f-415a-ac0c-ae7cfed9533c", "/link/networkinterface/66195ffb-5162-4c14-aaf3-426c5aafc1ae" ] }
Cheers, Boris
On Fri, Jan 17, 2014 at 9:41 AM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
Hi Boris, May I understand it implies the 2nd approach ? :)
{ resources: { id: ...
Cheers Jean
Le jeudi 16 janvier 2014 à 22:42 +0100, Boris Parak a écrit : > Hi Jean, > > rOCCI is built on top of the JSON spec and we are using the latter. At > least for me, the document implies this approach, although it's not > explicitly mentioned there. > > Cheers, Boris > > On Thu, Jan 16, 2014 at 3:02 PM, Jean Parpaillon > <jean.parpaillon@free.fr> wrote: > > Hi all, > > I have found no description of collection rendering in JSON draft. > > For those who implemented it, how do you achieve it ? > > > > If collection is a type on its own, we could have the following > > notation: > > { collection : [ id1, id2, id3, ... ]} > > > > We can also imagine the following: > > { resources: [ { id: ...}, { id: ... } ] } > > or > > { links: [ { id: ... }, { id: ... }] } > > > > > > Cheers, > > -- > > Jean Parpaillon > > Open Source Consultant > > Phone: +33 6 30 10 92 86 > > im: jean.parpaillon@gmail.com > > skype: jean.parpaillon > > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > > > _______________________________________________ > > occi-wg mailing list > > occi-wg@ogf.org > > https://www.ogf.org/mailman/listinfo/occi-wg
-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en
-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en
-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en
-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en