- occi-wg - lists.ogf.org

JSON rendering issue
by Jean Parpaillon 20 Jan '14

20 Jan '14

Hi, I've spent some hours implementing the rendering of resources attributes as defined in JSON spec and, finally, I think it can _not_ be done that way because its ambiguous. Let me give an example: let the following json document: { "attributes": { "com": { "example": { "default": { "type": "string" } } } } } Parsing this document, one can not say if this defines: - an attribute "com.example" with default value '{ "type": "string" }' - an attribute "com.example.default" with type "string" Given the interest of the community in JSON rendering and their implementations, I think we should quickly solve this issue and agree on a right syntax. Cheers, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

2 2

Re: [occi-wg] JSON collection rendering
by Florian Feldhaus 19 Jan '14

19 Jan '14

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? 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. 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-… 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. Cheers Florian Am 18.01.2014 um 18:46 schrieb Jean Parpaillon <jean.parpaillon(a)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(a)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(a)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(a)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(a)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(a)gmail.com >>>>>>>>> skype: jean.parpaillon >>>>>>>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> occi-wg mailing list >>>>>>>>> occi-wg(a)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(a)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(a)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(a)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(a)gmail.com > skype: jean.parpaillon > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/occi-wg

2 1

JSON collection rendering
by Jean Parpaillon 18 Jan '14

18 Jan '14

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(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

2 8

Re: [occi-wg] OCCI javascript client
by Florian Feldhaus 17 Jan '14

17 Jan '14

Hi Jean, I just recently started to experiment a bit with AngularJS to refresh my knowledge and write a OCCI factory. Once finished it should be very easy to create OCCI web portals with it. If you like we can share efforts. If you’d prefer a „pure“ JS client, we may also discuss about that. Cheers Florian Am 15.01.2014 um 14:13 schrieb Boris Parak <xparak(a)mail.muni.cz>: > Hi Jean, > > this might be interesting: https://github.com/ffeldhaus/occi.js > > Cheers, Boris > > On Wed, Jan 15, 2014 at 1:13 PM, Jean Parpaillon > <jean.parpaillon(a)free.fr> wrote: >> Hi all, >> I am looking for OCCI javascript clients implementations. >> Are there some people already working on it ? >> The ones I have found on github or else are not maitained since a long >> time. I have began writing one but efforts could be shared. >> >> Regards, >> -- >> Jean Parpaillon >> Open Source Consultant >> Phone: +33 6 30 10 92 86 >> im: jean.parpaillon(a)gmail.com >> skype: jean.parpaillon >> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org >> https://www.ogf.org/mailman/listinfo/occi-wg > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/occi-wg

5 4

OCCI javascript client
by Jean Parpaillon 15 Jan '14

15 Jan '14

Hi all, I am looking for OCCI javascript clients implementations. Are there some people already working on it ? The ones I have found on github or else are not maitained since a long time. I have began writing one but efforts could be shared. Regards, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

2 1

Invite: OCCI working group sessions at OGF 40
by Metsch, Thijs 08 Jan '14

08 Jan '14

Belayed happy new year to all! OGF 40 is taking place next week in Oxford and two working sessions have been scheduled [1]. Hence I wanted to invite you all too those sessions. If possible I will try to enable remote access through Skype or similar. If you have any topics for discussion feel free to ping me. Looking forward to meet those of you who will be available :) Cheers, -Thijs [1] http://www.ogf.org/dokuwiki/doku.php Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

4 4

Re: [occi-wg] About the OCCI compliance testsuite
by Andy Edmonds 20 Dec '13

20 Dec '13

Hi Gabriele, Roberto, Here's some related work on compliance from ETSI: ETSI Test descriptions (OCCI and CDMI): http://www.etsi.org/deliver/etsi_ts/103100_103199/103142/01.01.01_60/ts_103… TTCN3: http://ucaat.etsi.org/presentations/Towards%20a%20TTCN3%20%20Test%20Framewo… Which implementations of OCCI do you intend to test against? Cheers, Andy Andy Edmonds Æ Senior Researcher, ICCLab Institute of Information Technology Zürich University of Applied Sciences http://www.cloudcomp.ch, @dizz On 10 December 2013 12:28, Augusto Ciuffoletti <augusto(a)di.unipi.it> wrote: > I just checked, and the thesis is not yet on-line: you can watch for it > here: > > http://etd.adm.unipi.it/ETD-db/ETD-browse/browse > > What we did was: > -) to understand the code and document it > -) to upgrade it to recent versions of the tools it used > -) to correct a problem that seriously limited the coverage of the test > due to the opaque behavior of a library; the student used another library > thus partially solving the problem > > But the coverage of the test in itself is almost complete, as far as we > understood. Probably it might be a good idea to move it from the GAE, which > induces some limits. > > > 2013/12/10 Gabriele Giammatteo <gabriele.giammatteo(a)eng.it> > >> very good news! Indeed, we already planned to consider DoYouSpeakOcci >> also, but, also in this case the code I found here [1] is quite old, so we >> are very interested in taking a look at your prototype >> >> Thanks >> Gabriele >> >> [1] https://github.com/irf/doyouspeakocci >> >> >> ----------------------------------------------------------- >> Gabriele Giammatteo >> >> Research and Development Laboratory >> Engineering Ingegneria Informatica S.p.A. >> Via Riccardo Morandi, 32 00148 Roma - Italy www.eng.it >> >> email: gabriele.giammatteo(a)eng.it >> mob: +39 338 8506 202 >> tel: +39 06 8307 4031 >> skype: gabriele.giammatteo >> >> Respect the environment. Please don't print >> this e-mail unless you really need to. >> ----------------------------------------------------------- >> >> >> On 10/12/13 11:37, Augusto Ciuffoletti wrote: >> >> Hi Gabriele, >> >> we have just finished (the student that did the work discussed his >> thesis on Friday) working on the "doyouspeakocci" prototype. I guess this >> may be of interest for you. We are planning to diffuse the results soon on >> the maillist, but the thesis is online. >> >> >> 2013/12/10 Gabriele Giammatteo <gabriele.giammatteo(a)eng.it> >> >>> Dear Occi-Wg members, >>> this is my first email to the mailinglist, let me introduce myself. >>> I'm Gabriele Giammatteo and I'm a researcher in the cloud technologies >>> field at Engineering Group [0]. I and my colleague Roberto Ciotti are >>> currently working in an EU research project [1] where we have some >>> resources to develop compliance tools for cloud standards. >>> >>> We are looking at OCCI as first standard to cover and at the testsuite >>> included in the occi-wg repository [2] as codebase for developing a >>> compliance tool. >>> >>> We are willing to contribute to extend/complete this testsuite if >>> needed, but before, being new to this group, I'd like to ask some questions >>> to know the status and the "history" of this testsuite. >>> >>> a) I can see that last relevant commit on the code [3] is about two >>> years old. Is this code abandoned or its development is complete? Or the >>> development is continuing in another repository? >>> >>> b) The set of tests defined covers already all aspects of the standard >>> or there is room for new tests? If yes, which ones could be the most >>> interesting to implement? >>> >>> c) Is anybody currently doing (or planning to do) any further >>> development on it? We could be in touch in order to coordinate the efforts. >>> >>> d) Do you have any suggestion for improvements/new tests we can start >>> from? >>> >>> Thank you very much in advance for your replies, and, of course any >>> additional comment and/or suggestion is more than welcome! >>> >>> Best Regards, >>> Gabriele Giammatteo >>> Roberto Ciotti >>> >>> [0] >>> http://www.eng.it/ricerca/intro.dot?com.dotmarketing.htmlpage.language=1 >>> [1] http://ocean-project.eu/ >>> [2] >>> http://redmine.ogf.org/projects/occi-wg/repository/revisions/master/show/te…<http://redmine.ogf.org/git/standards/infrastructure-area/occi-wg.git> >>> [3] >>> http://redmine.ogf.org/projects/occi-wg/repository/revisions/7155871001951b… >>> >>> -- >>> ----------------------------------------------------------- >>> Gabriele Giammatteo >>> >>> Research and Development Laboratory >>> Engineering Ingegneria Informatica S.p.A. >>> Via Riccardo Morandi, 32 00148 Roma - Italy www.eng.it >>> >>> email: gabriele.giammatteo(a)eng.it >>> mob: +39 338 8506 202 >>> tel: +39 06 8307 4031 >>> skype: gabriele.giammatteo >>> >>> Respect the environment. Please don't print >>> this e-mail unless you really need to. >>> ----------------------------------------------------------- >>> >>> >>> >>> _______________________________________________ >>> occi-wg mailing list >>> occi-wg(a)ogf.org >>> https://www.ogf.org/mailman/listinfo/occi-wg >>> >>> >> >> >> -- >> Augusto Ciuffoletti >> Dipartimento di Informatica >> Università di Pisa >> 56100 - Pisa (Italy) >> >> >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org >> https://www.ogf.org/mailman/listinfo/occi-wg >> >> > > > -- > Augusto Ciuffoletti > Dipartimento di Informatica > Università di Pisa > 56100 - Pisa (Italy) >

2 1

OGF-40 WG sessions for OCCI
by Sill, Alan 17 Dec '13

17 Dec '13

Dear OCCI WG members, As you saw, the registration, venue and lodging information has been posted for the OGF 40 meeting 15-17 January in Oxford. This is immediately after the EGI Federated Cloud face-to-face meeting also in Oxford Monday and Tuesday of that same week, so this meeting should be of interest to the members of the OCCI working group. I would like to encourage you to take advantage of the opportunity to meet at this location. Here's what we know about the schedule so far. - Six WG sessions (so at least 1 1/2 days) have been requested by NSI - Two working sessions have been requested by NML - Two working sessions have been requested by CAOPS - A special DFDL demo and presentation will probably be scheduled for Thursday Beyond this, I have sent an appeal to the area directors to get in contact with their groups ASAP so that a schedule can be posted. Thijs or Andy should be able to make a request on behalf of the group, and we are open to BOFs, plugfests, working group sessions etc. during the conference. The call for session proposals for you to add session requests is here: - http://www.ogf.org/dokuwiki/doku.php/events/ogf-40/call_for_session_proposa… And the list of sessions requested so far is here: http://redmine.ogf.org/projects/ogf-40/issues Please discuss among your group and get in touch with us and fill out a request so that a schedule can be posted! Thanks, Alan Sill VP of Standards OGF

1 0

OCCI and PaaS Interoperability
by Eman Hossny 11 Dec '13

11 Dec '13

Dear OCCI-wg members, I'm new to this mailing list & I'm a PhD student. I'm searching in solving the heterogeneity problem inside the PaaS platforms. as I know that the OCCI is the de-facto standard in cloud computing for allowing interoperability; I read the three docs of the OCCI (i.e., OCCI core, http rendering, and infrastructure) But I don't know who I can benefit from OCCI after reading this three docs? can anyone advice me in this issue? -- Eman Hossny, Teacher Assistant, Computer Science Department, Faculty of Computers and Information Cairo University, Egypt

3 2

XML rendering
by Augusto Ciuffoletti 11 Dec '13

11 Dec '13

Hi Jean, I have completed the exercise of translating to XML the example in the document (compose.pdf). There is one XML that describes the mixins specific for the provider (example.xml), and the xml document that describes the entities that implement the example in the document (occi-monitoring-example.xml). They are uploaded in the "monitoring" branch. I have left your comments in the occi-monitoring-example.xml complaining about the fact that mixin attributes "melt" into the resource in a completely opaque way. On my side, I add that it is also impossible to characterize an attribute with any sort of semantic (in my case, input, control, metric). About the occi.xsd document: -) line 113: amyURI instead of anyURI -) the attribute type <xs:complexType name="attributeType"> <xs:sequence> <xs:element name="value" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:string"></xs:attribute> <xs:attribute name="value" type="xs:string"></xs:attribute> </xs:complexType> The two attributes are ok (name+value) but the unbounded sequence of URIs puzzles me: what is its meaning exactly. And, overall, this is not the "attribute" as defined in the core model, upper right corner of fig. 2: this is represented as the "attributeSpecType", right? Is there a relationship between the two? I guess no. Also: I have not found an easy way to test the example: do you have an inexpensive suggestion for me? Bye! Augusto PS: ah, is there interest regarding XMPP? -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

2 3