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