[occi-wg] OCCI Core/Rendering feedback

[Ralf Nyren]

Hi Jean,

Many thanks for your feedback, see comments inline.

On Mon, 23 Sep 2013 12:45:13 +0200, Jean Parpaillon
<jean.parpaillon at free.fr> 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].
 
> - 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core.pdf
Type: application/octet-stream
Size: 243828 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20130924/f221550e/attachment-0001.obj>