[occi-wg] OCCI Core/Rendering feedback

[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:

- 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_parser.yrl
-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jean_parpaillon.vcf
Type: text/x-vcard
Size: 230 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20130923/923a468c/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20130923/923a468c/attachment.pgp>