[occi-wg] JSON collection rendering
Jean Parpaillon
jean.parpaillon at free.fr
Sun Jan 19 15:52:05 EST 2014
Hi,
Le dimanche 19 janvier 2014 à 18:25 +0100, Florian Feldhaus a écrit :
> Hi,
>
> I’d like to give some comments to the issues raised in this thread.
>
> 1.) OCCI Collections
>
> I agree that there is some confusion around OCCI Collections and it would be good if we (the OCCI WG) would review the definition of OCCI Collections defined in OCCI Core. There it is stated, that
> "One or more resource instances associated with the same Kind or Mixin instance, automatically form a collection.“
> For some implementations (e.g. in the rOCCI implementation of OCCI), OCCI Collections are interpreted as collections of OCCI instances (e.g. OCCI Kind instances, OCCI Mixin instances, OCCI Action instances, OCCI Resource instances, OCCI Link instances). OCCI Collections according to OCCI Core are in my understanding limited to only the OCCI Resource instances of the same OCCI Kind. I would prefer to broaden the definition in OCCI Core to reflect the interpretation of rOCCI, but I’m totally biased. What are your opinions about OCCI Collections?
IMO, rather than extending the term of collection to collection of
categories or actions, the OCCI core spec should differentiate (and
define, then) the following sets of objects:
(a) collection of entities associated with the same kind or mixin: the
actual definition of OCCI collection
(b) collection of entities associated with different kind or mixins. For
instance, the list of entities under a given path.
(c) collection of categories and actions, like returned by a GET /-/
query or belonging to a given OCCI extension.
I think a definition for theses objects could allow to define rendering
independantly from the protocol context.
For instance, defining (c) precisely could allow to define a
representation of the capabilities of the server not linked with the
HTTP GET /-/ request.
>
> 2.) Full Rendering vs. Listing in OCCI JSON Rendering
>
> Let’s first be clear about the use case. I see the following use cases:
> A.) Render detailed information about one or more OCCI instances for create, read and update operations
> B.) Render a list of unique identifiers for add (e.g. to mixing), read, update and delete operations
>
> Regarding A.) I think the OCCI JSON Rendering document is complete, but may state more specific how collections are rendered (e.g. kinds, mixins and actions returned by the discovery interface).
>
> Regarding B.) this leads again to the discussion of unique identifiers and locations. For OCCI Kinds, OCCI Mixins and OCCI Actions, the unique identifier ist scheme+term (e.g. http://schemas.ogf.org/occi/infrastructure#compute). For OCCI Entities the unique identifiers is the id attribute (defined as being a URI). The text/uri-list is a good and compact way to render the id attribute. I don’t see any benefit of rendering only the id attributes in JSON. The only question is, if only the id attribute or the absolute / relative location of the resource should be rendered. IMHO this is not yet clear in the HTTP Rendering document.
>
IMO, a rendering SHOULD NOT depend on another one as it is the case if a
collection of entity ids as no definition in json. It really limits the
possibility of extending to other protocols, where rendering negociation
is not possible for instance.
> I do see a benefit of including pagination and better querying in the new OCCI HTTP Transport document to reduce the load on the server. In my opinion the split of the Text rendering and the HTTP Transport should have high priority in the next time. I’m willing to contribute, but need someone to push me. The first draft can be found here:
> http://redmine.ogf.org/projects/occi-wg/repository/revisions/protocol-data-format-split/entry/http_protocol.tex
> 3.) OCCI JSON Rendering Review
>
> Please review the OCCI JSON Rendering document and add your comments in Redmine
> http://redmine.ogf.org/projects/editor-pubcom/boards/19
>
> If you have problems using Redmine, please send a mail to the OCCI WG mailinglist so that we can solve your Redmine problems and receive your comments on the document.
>
Ok for contributing to this document.
> Cheers
> Florian
>
Cheers
Jean
> Am 18.01.2014 um 18:46 schrieb Jean Parpaillon <jean.parpaillon at free.fr>:
>
> > 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 at 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 at 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 at 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 at 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 at gmail.com
> >>>>>>>>> skype: jean.parpaillon
> >>>>>>>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> occi-wg mailing list
> >>>>>>>>> occi-wg at 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 at 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 at 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 at 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 at gmail.com
> > skype: jean.parpaillon
> > linkedin: http://www.linkedin.com/in/jeanparpaillon/en
> >
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at 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 at gmail.com
skype: jean.parpaillon
linkedin: http://www.linkedin.com/in/jeanparpaillon/en
More information about the occi-wg
mailing list