Wow! :-) I'm unfortunately late to all these discussion, so I'm in catch up mode... With regard to the segmented approach, it's very wise. However, there's a binding aspect to the approach in general that is missing, certainly for part (A). That is (and yes I'm surprised myself to say this) there's a model missing which unifies all these concepts. Now I'm not advocating MDA or anything elaborate in that vein but I would advocate something that could be used, by those wanting to, as a means to minimise confusion, communicate effectively, isolate possible architectural & technical dependencies, hell even validate requests (they're just a model containing verbs, nouns and attributes ;-)). By having such a model, the issue of part (B) then somewhat fades to a non-issue - part (B) is then only concerned with various rendering of the model, be it in JSON, XML etc. I believe that if we can begin to express the {noun{verb{attribute}}} vector for each valid entity that should be exposed on an external interface of an infrastructure provider then many of the technical discussions will almost be rhetorical via reference of the model. It is this {noun{verb{attribute}}} vector that can be easily mapped to other modelling methodologies - imagine it in OO-terms or relational modelling terms etc. Not only that but a model can be accessed/exposed using various "architectural styles" for example REST, RPC, message-oriented. By choosing such an approach, the communication of our collective ideas will also be efficient and accurate. I am, however careful nor would want that such an effort end up reinventing something like OVF or any of the VMAN efforts being carried out in DMTF. As such having a reference model that describes our "concerns" ({noun{verb{attribute}}}) will allow us see the wood from the trees and hopefully beyond the forest, giving us an edge and, with fingers crossed, complimenting existing standards. Not wanting to divert the original conversation on the core entities within the OCCI, I've renamed (forked) the subject of the mail. Regards, Andy PS: I'm digging the energy here in the group! Andy Edmonds skype: andy.edmonds tweets: @dizz tel: +353 (0)1 6069232 IT Research - IT Innovation Centre - Intel Ireland Ltd. Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Richard Davies Sent: 16 April 2009 20:50 To: occi-wg@ogf.org Subject: Re: [occi-wg] Syntax of OCCI API Definitely agree with this approach. For (A), I think it's actually nouns (e.g. servers), verbs (e.g. start) and noun attributes (e.g. memory). All of these can be consistent between different bindings. For (B), as per my many posts I'm very keen that the text and JSON versions are in extremely simple format - just a flat list of key-value attributes for each noun. I'm much less concerned about the XML syntax. Richard. Andre Merzky wrote:
So, what this discussion basically boils down to is, that this group should do two steps:
A) define the nouns and verbs for the API, and nail down semantics for them
B) do different bindings for the result of (A)
Looks sensible (to me), and there seem to be enough people around who can check the process in (A) for implementability in the various options of (B).
Is that what it is going to be?
Andre
occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.