[occi-wg] OCCI Core/Rendering feedback

[Jean Parpaillon]

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
> <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].
>  

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 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/20130926/57b8864e/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/20130926/57b8864e/attachment.pgp>