Documents for OCCI rev 1.2
Dear all, Thanks to the help of many people we are close to putting the documents defining the revision 1.2 of OCCI into public comment! To do so I want to ask all of you to review the documents as is and raise any possible show stoppers before putting these in public comment. We propose that the following documents will be put into public comment asap: As Recommendations: * OCCI Core rev 1.2 which will obsolete GFD-R 183. A Errata has been attached to the end of the document * OCCI Infrastructure rev 1.2 which will obsolete GFD-R 184. A Errata has been attached to the end of the document * OCCI Protocol which is a newly written document describing how OCCI entities are dealt with using HTTP. This will obsolete GFD-R 185. * OCCI Text rendering which is a newly written document describing how OCCI entities are rendered using a text format. This will obsolete GFD-R 185. * OCCI Json rendering which is a newly written document describing how OCCI entities are rendered using a JSON format. * OCCI Platform extension describing how a PaaS boundary interface can be modeled. * OCCI SLA extension describing how a SLAs can be managed As Informational documents: * EGI FedCloud Profile * Monitoring for OCCI We will soon decide about the following documents: * Notifications for OCCI * OCCI-DRMAA binding (together with DRMAA-wg) A PDF version of the documents is attached - The source can be found in our git repository on the master branch. Again many thanks for all contributions and help offered! Cheers, -Thijs 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
Dear Thijs, I had read the Core and Text Rendering documents and found some mistakes: OCCI Core: - In the first sentence OCCI is defined as RESTful Protocol, but the text behind the second bullet says that the Core Model is HTTP independent. I think it would be very beneficial to keep the core model HTTP independent, which is also the advantage of having the Redering specifications in separate documents. - Figure 2 illustrates that Category has a List of Attributes which is also specified in the text on page 7, but Table 2 does not list the Attribute's property. - The Attribute's property "type" is in figure 2 of type String, but defined in section 5.3.2 as an enum {Object, List, Hash}. Besides this inconsistency, the type of Attributes can be everything as defined in the other specifications. Therefore I would prefer to String!? - In table 7 the type of a mixin is Kind? This should be Mixin, right? OCCI Text Rendering: - It would be good to write out abbreviations in the beginning (e.g. ABNF, CRLF, etc.). - In section 6 the first two sentences does not fit together :-) In general, I think that the HTTP protocol can be used for examples but should not be illustrated as obligated. Best regards Alexander -- M.Sc. Dipl.-Ing. Alexander Stanik Technische Universität Berlin Faculty of Electrical Engineering and Computer Science Department of Telecommunication Systems Complex and Distributed IT Systems Secr. EN 59 Einsteinufer 17, 10587 Berlin Phone: +49 (30) 314-22616 Fax: +49 (30) 314-21060 E-Mail: alexander.stanik@tu-berlin.de<mailto:alexander.stanik@tu-berlin.de> WWW: http://www.cit.tu-berlin.de Von: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] Im Auftrag von Metsch, Thijs Gesendet: Donnerstag, 19. März 2015 13:33 An: occi-wg@ogf.org Betreff: [occi-wg] Documents for OCCI rev 1.2 Dear all, Thanks to the help of many people we are close to putting the documents defining the revision 1.2 of OCCI into public comment! To do so I want to ask all of you to review the documents as is and raise any possible show stoppers before putting these in public comment. We propose that the following documents will be put into public comment asap: As Recommendations: * OCCI Core rev 1.2 which will obsolete GFD-R 183. A Errata has been attached to the end of the document * OCCI Infrastructure rev 1.2 which will obsolete GFD-R 184. A Errata has been attached to the end of the document * OCCI Protocol which is a newly written document describing how OCCI entities are dealt with using HTTP. This will obsolete GFD-R 185. * OCCI Text rendering which is a newly written document describing how OCCI entities are rendered using a text format. This will obsolete GFD-R 185. * OCCI Json rendering which is a newly written document describing how OCCI entities are rendered using a JSON format. * OCCI Platform extension describing how a PaaS boundary interface can be modeled. * OCCI SLA extension describing how a SLAs can be managed As Informational documents: * EGI FedCloud Profile * Monitoring for OCCI We will soon decide about the following documents: * Notifications for OCCI * OCCI-DRMAA binding (together with DRMAA-wg) A PDF version of the documents is attached - The source can be found in our git repository on the master branch. Again many thanks for all contributions and help offered! Cheers, -Thijs 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
Hi, Did I miss something in what you are flagging? This is not a contradiction. REST design is not dependent on being implemented in HTTP -- REST can be achieved with any transport. Alan On Mar 24, 2015, at 8:04 AM, Stanik, Alexander <alexander.stanik@tu-berlin.de<mailto:alexander.stanik@tu-berlin.de>> wrote: - In the first sentence OCCI is defined as RESTful Protocol, but the text behind the second bullet says that the Core Model is HTTP independent. I think it would be very beneficial to keep the core model HTTP independent, which is also the advantage of having the Redering specifications in separate documents.
Um, well, not really. REST is just REST; its a design pattern that can be implemented using any protocol. It's true that REST-over-HTTP is the most popular form, but there is nothing about stating that a design is RESTful that implies the use of HTTP. Alan On Mar 24, 2015, at 2:36 PM, Papaspyrou, Alexander <Alexander.Papaspyrou@adesso.de<mailto:Alexander.Papaspyrou@adesso.de>> wrote: Well, it depends on how picky you are. Albeit, this can be easily fixed by changing REST to CRUD in the core specs – that’s pretty much what we meant when saying „RESTful protocol“. @Thijs: Correct me if I am wrong (you will, I bet ^^) -A. -- Dr. Alexander Papaspyrou adesso AG Head of IT Operations Stockholmer Allee 20<x-apple-data-detectors://2/0> 44269 Dortmund<x-apple-data-detectors://2/0> T +49 231 7000-2394<tel:+49%20231%207000-2394> F +49 231 7000-1000<tel:+49%20231%207000-1000> M +49 162 2808483<tel:+49%20162%202808483> E alexander.papaspyrou@adesso.de<mailto:alexander.papaspyrou@adesso.de> www.adesso.de<http://www.adesso.de/> blog.adesso.de<http://blog.adesso.de/> From: <Sill>, Alan Sill Date: Dienstag, 24. März 2015 14:15 To: "Stanik, Alexander" Cc: "occi-wg@ogf.org<mailto:occi-wg@ogf.org>" Subject: Re: [occi-wg] Documents for OCCI rev 1.2 Hi, Did I miss something in what you are flagging? This is not a contradiction. REST design is not dependent on being implemented in HTTP -- REST can be achieved with any transport. Alan On Mar 24, 2015, at 8:04 AM, Stanik, Alexander <alexander.stanik@tu-berlin.de<mailto:alexander.stanik@tu-berlin.de>> wrote: - In the first sentence OCCI is defined as RESTful Protocol, but the text behind the second bullet says that the Core Model is HTTP independent. I think it would be very beneficial to keep the core model HTTP independent, which is also the advantage of having the Redering specifications in separate documents. ------------------------------------------------------- >>> business. people. technology. <<< ------------------------------------------------------- adesso AG mit Sitz in Dortmund Vorstand: Christoph Junge, Michael Kenfenheuer (Co-Vors.), Dr. Rüdiger Striemer (Co-Vors.) Vorsitzender des Aufsichtsrates: Prof. Dr. Volker Gruhn Amtsgericht Dortmund HRB 20663
I agree with Alan. IMHO: REST abstracts certain features from HTTP, in order to have a guideline to implement better Web applications. It is strongly bound to HTTP (so I do not consider as a problem to have HTTP examples in our doc) but it is not tightly bound to that transport. Section 4 of the 2002 paper by Fielding and Taylor describes the REST architectural elements without reference to HTML. In sect. 5 they use HTTP, together with other protocols, to describe an example, and they explicitely note that "Although the Web’s primary transfer protocol is HTTP, the architecture includes seamless access to resources that originate on many pre-existing network servers..." (in sect. 5.2). And section 7.2 is entitled "REST applied to HTTP". However the point raised by Alexander is relevant, and should be clarified in the paper. 2015-03-24 19:47 GMT+01:00 Sill, Alan <alan.sill@ttu.edu>:
Um, well, not really. REST is just REST; its a design pattern that can be implemented using any protocol. It's true that REST-over-HTTP is the most popular form, but there is nothing about stating that a design is RESTful that implies the use of HTTP.
Alan
On Mar 24, 2015, at 2:36 PM, Papaspyrou, Alexander < Alexander.Papaspyrou@adesso.de> wrote:
Well, it depends on how picky you are. Albeit, this can be easily fixed by changing REST to CRUD in the core specs – that’s pretty much what we meant when saying „RESTful protocol“.
@Thijs: Correct me if I am wrong (you will, I bet ^^)
-A.
--
Dr. Alexander Papaspyrou adesso AG Head of IT Operations Stockholmer Allee 20 44269 Dortmund
T +49 231 7000-2394 <+49%20231%207000-2394> F +49 231 7000-1000 <+49%20231%207000-1000> M +49 162 2808483 <+49%20162%202808483> E alexander.papaspyrou@adesso.de
www.adesso.de blog.adesso.de
From: <Sill>, Alan Sill Date: Dienstag, 24. März 2015 14:15 To: "Stanik, Alexander" Cc: "occi-wg@ogf.org" Subject: Re: [occi-wg] Documents for OCCI rev 1.2
Hi,
Did I miss something in what you are flagging? This is not a contradiction. REST design is not dependent on being implemented in HTTP -- REST can be achieved with any transport.
Alan
On Mar 24, 2015, at 8:04 AM, Stanik, Alexander < alexander.stanik@tu-berlin.de> wrote:
- In the first sentence OCCI is defined as RESTful Protocol, but the text behind the second bullet says that the Core Model is HTTP independent. I think it would be very beneficial to keep the core model HTTP independent, which is also the advantage of having the Redering specifications in separate documents.
------------------------------------------------------- >>> business. people. technology. <<< -------------------------------------------------------
adesso AG mit Sitz in Dortmund Vorstand: Christoph Junge, Michael Kenfenheuer (Co-Vors.), Dr. Rüdiger Striemer (Co-Vors.) Vorsitzender des Aufsichtsrates: Prof. Dr. Volker Gruhn Amtsgericht Dortmund HRB 20663
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)
Hi all, If there are no major objections I will start the process to get the documents into public comment today. Cheers, -Thijs From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Metsch, Thijs Sent: Thursday, March 19, 2015 1:33 PM To: occi-wg@ogf.org Subject: [occi-wg] Documents for OCCI rev 1.2 Dear all, Thanks to the help of many people we are close to putting the documents defining the revision 1.2 of OCCI into public comment! To do so I want to ask all of you to review the documents as is and raise any possible show stoppers before putting these in public comment. We propose that the following documents will be put into public comment asap: As Recommendations: * OCCI Core rev 1.2 which will obsolete GFD-R 183. A Errata has been attached to the end of the document * OCCI Infrastructure rev 1.2 which will obsolete GFD-R 184. A Errata has been attached to the end of the document * OCCI Protocol which is a newly written document describing how OCCI entities are dealt with using HTTP. This will obsolete GFD-R 185. * OCCI Text rendering which is a newly written document describing how OCCI entities are rendered using a text format. This will obsolete GFD-R 185. * OCCI Json rendering which is a newly written document describing how OCCI entities are rendered using a JSON format. * OCCI Platform extension describing how a PaaS boundary interface can be modeled. * OCCI SLA extension describing how a SLAs can be managed As Informational documents: * EGI FedCloud Profile * Monitoring for OCCI We will soon decide about the following documents: * Notifications for OCCI * OCCI-DRMAA binding (together with DRMAA-wg) A PDF version of the documents is attached - The source can be found in our git repository on the master branch. Again many thanks for all contributions and help offered! Cheers, -Thijs 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 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
participants (5)
-
Augusto Ciuffoletti -
Metsch, Thijs -
Papaspyrou, Alexander -
Sill, Alan -
Stanik, Alexander