Hi, As proposed during our session in last plugfest, here is my feedback about OCCI Core (and rendering). Background: - while working on CompatibleOne project, try to propose an XML representation of OCCI - developing an erlang-based OCCI framework (erocci) Comments; == == Understandability == It took me a lot of time to understand the categorization meta-model. These comments are highly subjectives then... Nevertheless, I think the following items could help understand the specifications more quickly: - In a general way, OCCI Core specification could provide some more examples to understand the categorization model. HTTP and infrastructure specifications have been of greater help than Core. - OCCI Core specifications could clarify the link between OCCI types and notions most of developers are familiar with, like: objects, classes, interfaces, polymorphisms, etc. == == Missing == Some elements should be present in the OCCI Core specification for avoiding any ambiguity in the implementations. - attribute default value: when an attribute is required and immutable, it is up to the implementation to choose a default value when creating the resource. The specification should provide a default value in this case. - attribute base typing: the specification should formalize base types for attributes. XML schema specification provides 44 "builtin" types[0], for instance. - attribute type extension/restriction: in Infrastructure specification, for instance, extended types are used, but not formally defined: enum, ip, mac address, etc. The OCCI Core specification should provide some mechanisms to extend/restrict base types: enumeration, string patterns, decimal precision ?, integer range ?, etc. - state machine: many actions are defined with the target state of the resource. The OCCI specification may provide a way to define state-machine handling in a formal way. I've been working on the Aeolus project[1] which published really interesting model for planification of resources handling on cloud systems. I'm still in touch with them and they look interested in using OCCI to implement their system. This is quite mid term action but I will keep you informed if something interesting comes from that. == == Rendering specifications == All rendering specifications should include a formal grammar or schema. Andy Edmonds has provided a text/plain and text/occi rendering antlr grammar. Nevertheless, many of quoted values need to be parsed again to get the full structure of the request. I'm not aware enough of antlr to know if we can do better, but that be nice. Based on that, I've also written a Yacc-style grammar for text/plain[3] (exactly Yecc, an erlang implementation), but I have the same problem: QUOTED_VALUE is a terminal. Anyway, I strongly suggest this grammar to be part of the OCCI HTTP rendering specifications, maybe as an appendix. I've discovered (this week-end :) ) that JSON schemas specification exist, and their are implemented in a lot of libraries, JSON specification should then include a schema of this kind. Same for XML... Last but not least, we may agree on a reference meta-language to describe OCCI extension and include such description as appendix to each extension. AFAIK, XML is the most complete meta-language for this purpose. Comments welcome, Best regards, Jean [0] http://www.w3.org/TR/xmlschema-2/#built-in-datatypes [1] http://www.aeolus-project.org/ [2] http://www.upsilon.cc/~zack/research/publications/sefm2012-aeolus.pdf [3] https://github.com/jeanparpaillon/erocci/blob/master/src/rendering/occi_pars... -- 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