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
I'm not following this group from the very beginning, and I do not remember a discussion about XML as a rendering option. Maybe Andy or Thijs have a record about this. JSON appears as more compact wrt XML, but probably XML has a richer set of utilities and is overall more established: any other relevant difference? There is an ongoing effort on a JSON rendering. I think that schemas are unable to capture certain semantic aspects of OCCI specs, so their application, while useful, is not sufficient. Certainly the availability of libraries for navigating complex/deep structures is relevant.
Dear Augusto, Sorry for not being clearer, but this discussion has just begin last week at plugfest, and I've sent an email trying to summarize, with a link to my presentation. So let's try to explain my proposals. Unfortunately, there is no perfect format. JSON format is more compact, but some important features are missing in order to use it for a full specification. Utilities (parsers, validators and such) are important for both formats, a little bit less for JSON but growing. IMO, JSON rendering must be defined for its wide use in web applications and some NoSQL storage (Riak...). Nevertheless, XML/XSD has the following advantages for formal specs: - comments included: both formal (appinfo) and informal (annotation) - string typing: 44 base types + extensions/restrictions. About the completness of schemas, I've been asked several times this question, so I think a little bit of clarification is needed: 1/ entities must be validated against their category description: we can use schemas for that, ie each category is described with a schema. In that case, resource validation can be really fast to implement, but there is still no formal way of describing categories (XML schema should be restricted for that), 2/ category description should be validated against a grammar. This category description, then must provide the implementation enough information to validate entities: actually OCCI grammar (for text/occi) is formal but can not embed a lot of semantic about attribute types, attribute multiplicity and such. The goal of my XML representation is to fullfill need of 2/. I make the assumption it is more important to have formal OCCI representation for extensions, and write a little bit of code to achieve 2/ rather than having 1/ done by existing tools (XML validators) but not being able to achieve 2/. Regards, Jean Le 23/09/2013 16:59, Augusto Ciuffoletti a écrit :
I'm not following this group from the very beginning, and I do not remember a discussion about XML as a rendering option.
Maybe Andy or Thijs have a record about this. JSON appears as more compact wrt XML, but probably XML has a richer set of utilities and is overall more established: any other relevant difference? There is an ongoing effort on a JSON rendering.
I think that schemas are unable to capture certain semantic aspects of OCCI specs, so their application, while useful, is not sufficient. Certainly the availability of libraries for navigating complex/deep structures is relevant.
-- 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
Hi Jean,
Many thanks for your feedback, see comments inline.
On Mon, 23 Sep 2013 12:45:13 +0200, Jean Parpaillon
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:
Which version of the OCCI Core doc did you read? There happens to be a new version of this document which has not been published yet but contains some errata fixes which might help clarify a thing or two. It should be in the list archives but I am attaching a freshly built PDF from our git master [1].
- 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.
Yes I know, it is much easier to start with reading the HTTP/infra specs. I guess I am the one to blame for the abstractness of the Core doc :-P
- OCCI Core specifications could clarify the link between OCCI types and notions most of developers are familiar with, like: objects, classes, interfaces, polymorphisms, etc.
You mean like an example section where the OCCI types are described in common OO-lingo? I think that is a very good idea.
== == 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.
Please have a look at the latest Core and see if the errata solves this.
- 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.
I believe this was discussed a couple of times and the outcome was basically that it perhaps not was worth the trouble to have detailed validation rules expressed in the query interface. The server can always choose to refuse an update if the object attributes does not validate. I.e. keep it simple. Not sure if I saw that many use cases where the client actually needed to know the details of the attribute validation mechanisms. Do you have some use cases which you feel important?
- 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.
Sounds cool =) regards, Ralf [1] http://redmine.ogf.org/git/standards/infrastructure-area/occi-wg.git
Hi Ralph, Le 24/09/2013 13:31, Ralf Nyren a écrit :
Hi Jean,
Many thanks for your feedback, see comments inline.
You're welcome. Thanks for the original work !
On Mon, 23 Sep 2013 12:45:13 +0200, Jean Parpaillon
wrote: 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:
Which version of the OCCI Core doc did you read? There happens to be a new version of this document which has not been published yet but contains some errata fixes which might help clarify a thing or two. It should be in the list archives but I am attaching a freshly built PDF from our git master [1].
Indeed, I based my comments on the version on occi-wg.org website. So, the version on git has many interesting improvements. Most of my comments are then irrelevant :P
- 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.
Yes I know, it is much easier to start with reading the HTTP/infra specs. I guess I am the one to blame for the abstractness of the Core doc :-P
- OCCI Core specifications could clarify the link between OCCI types and notions most of developers are familiar with, like: objects, classes, interfaces, polymorphisms, etc.
You mean like an example section where the OCCI types are described in common OO-lingo? I think that is a very good idea.
Yes, for instance, that may help.
== == 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.
Please have a look at the latest Core and see if the errata solves this.
Yes.
- 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.
I believe this was discussed a couple of times and the outcome was basically that it perhaps not was worth the trouble to have detailed validation rules expressed in the query interface. The server can always choose to refuse an update if the object attributes does not validate. I.e. keep it simple.
Not sure if I saw that many use cases where the client actually needed to know the details of the attribute validation mechanisms. Do you have some use cases which you feel important?
In fact, I see 2 usages for specifications which have not been decoupled so far but could be if we agree on a more expressive one, like XML. The first is about exposing capacities through the query interface. I agree with exposing validation rules may not be relevant there. The second one is to be able to increase the coherence between implementations by being able to "feed" OCCI frameworks with formal specifications. An example is about the date and time, which have many possible representations. Of course, if we don't expose the full specification of attribute type, but just a reference to it, we break the model of OCCI where client can discover everything from the server. A compromise can then be to not allow basic types extensions/restriction, but providing more basic types. The 44 basic types of XML schema are a good candidate. Sorry if this discussion has already been raised many times, but uri and date, for instance, are really basic types that could be interesting to define.
- 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.
Sounds cool =)
regards, Ralf
[1] http://redmine.ogf.org/git/standards/infrastructure-area/occi-wg.git
Regards, -- 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
participants (3)
-
Augusto Ciuffoletti
-
Jean Parpaillon
-
Ralf Nyren