Andy
andy.edmonds.be

2010/9/4 Csom Gyula <csom@interface.hu>

Agree:) Some notes and questions:

(1) Since OCCI has itw own, special view on the "type system" hence a separate section on the topic
would be useful. Besides extensions as Thijs proposed, I think the general type concept
could/should be described. This could help users (either implementors, extenders or providers)
to get the point and could shorten the learning curve.

To my understanding (according to the doc and the previous chat) OCCI's type system has the
following 4 characteristics:

* Extensible: OCCI lets providers extend the builtin types by (1) subclassing resources and (2) creating
user defined categories.

Yep :-)

* Composable: OCCI supports multiple-inheritance-like feature through a mixin like model - that is
(generic) behaviour can be introduced to OCCI resouces by attaching categories.

Yep :-) Just to clarify new behaviours can be introduced to resource instances (this supports the next point you make)

* Static: Similar to traditional OO languages and in contrast with dynamic languages, OCCI uses
a static type system. Once defined, a type becomes frozen and cannot be modified later. That is if
someone wants to introduce a new behaviour to an existing type she can but in order to that she
has to subclass the original type, or more explicitely: new attributes, categories cannot be added
to already defined types.

Yep :-)

* Discovarable: OCCI has builtin reflection capabilities: through Categories one could query
the available attrbiutes and actions of a resource. So if someone wants to implement some
generic client behaviour (for instance a generic UI client) she gots some support from the protocol.

Yep :-) Minor point but I'd call this reflection as opposed to discoverability.

I just wanted to sum it up cause I think the above feature should be described and also because my
questions are related to these topics:)

These four points above should be placed into the model section.

(2) Extensibility: no question. Maybe within 4.1.2.1 (or within a separate chapter) it could be further
emphasized that extensibility is a recursive feature, ie. OCCI supports extension of extensions.
Its just a documentation note, since support for inheritance tree is implicitely quite clear from the
following sentence on categories:

"The related set MUST include a, direct or indirect, reference to the Resource base type category".

As far as I understand "indirect" is the keyword here:)

(3) Composable: Namespace support (like occi.xxx.yyy) or kinda could be handled/clarified at this
level. That is the spec could/should clarify either (1) how to avoid name collisions or (2) how name
resolution works in such cases.

To avoid namespace clashes we've defined that only the OCCI spec can use the occi.* for attribute names and use http://schemas.ogf.org/occi/* for scheme in category. After that there is no further normative guarantee other than the opportunity for implementors to register their extensions with the working group (through mail and entry into a planned wiki registry)

Also I think examples could/should be discovered/provided for the mixin feature since the domain model
in its current form (including the Core (ie. Kind, Resource, Action and Link) and the Infrastructure
(Compute, Network and Storage) represents just a single inheritance tree. Is there a plan to do so or
some existing example I missed?:)

Agreed and yes there should be some examples floating about. Maybe:

http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ExamplesUseCaseScenarios

and

https://docs.google.com/Doc?docid=0AS0AExvzzYt7YWQ2enFodmt6czlfMzRnM25mMnJmZA&hl=en

(4) Discovery: It is clear that for every Cloud object at least one Category should be assigned (ie.
Kind.categories' multiplicity is 1..*). However it is not clear whether all attributes and actions a Cloud object supports should be exposed through Categories or a Resource can introduce its own
attributes/actions not exposed (hence not discovarable) through any Category.

IMO the resource should be bound to the contract it presents through categories and so not introduce "backdoor" attributes/actions. We can guarantee this in the spec and recommend that those wishing to extend follow best practices. Those best practises should be detailed in a section dedicated to those wanting to create their own extensions.

For instance:

Compute is assigned the http://schemas.ogf.org/occi/infrastructure#compute Category. Compute has some attributes within the occi.compute namespace (architecture, cores, hostname, etc.) and also some actions (start, stop, etc.). Now, in this particular case, the question is whether someone could query the Compute attribute (names), actions through the compute category or should she consult the spec?

Why could they not do both?

(5) Kind notation. I am just wondering whether the term is an intuitive one or not. Implicitely it has
type/class semantics (at least for me:)). What's more as far as I remember/know the term "kind"
historically was introduced in place of "type", but could be wrong. Anyway Kind represents the
attributes that is common to all cloud objects and not the attributes of classes (ie. Kind is not for
reflection). In programming languages this distinction is made through Object and Class classes.
The former represents the common behaviour of all objects and the latter defines the special
characteristics of types. Maybe another notation? that better reflects that "Kind" is about
objects/entites and not about classes/types? that also clearly distinguish it from Category?

Historically, Kind was a synonym for Resource. I'm not sure of what other name we could use but perhaps if we simply explained the difference in the spec that should suffice.

Cheers
Gyula

________________________________
Feladó: occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org> [occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com>]
Küldve: 2010. szeptember 4. 12:54
Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@ogf.org>
Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure

Great stuff - Thanks Ralf! Especially of keeping the HTTP stuff out of the Core :-) Looks much better now.

Just wondering if we should move the extensibility sections to one section...but that's just an editorial thought.

Cheers,

-Thijs

-----Original Message-----

From: occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren
Sent: Sat 04-Sep-10 12:41

To: occi-wg@ogf.org<mailto:occi-wg@ogf.org>
Subject: [occi-wg] Update of Core & Models and Infrastructure

Hi,

I have finished and uploaded a rather significant update of the Core &
Models [1] document. The Infrastructure document [2] has been updated
accordingly while the HTTP Rendering document is still in the works.

The Core & Models changelog:
- Updated UML diagram. Fixes the issue with Actions.
- Updated and re-structured description/definition of the base types.
Please read everything through.
- Templates definition added, it is just a Category but without the
requirement to be a type construct.
- Added full description of the Category base type.
- Removed all REST and HTTP stuff. This information will reappear in the
HTTP Rendering document.
- HTTP related Open Issues will reappear in the HTTP Rendering document.
- Extension rules properly defined.
- Discovery mechanism from the Core perspective.

Hopefully the new version should be a lot more consistent and only address
things relevant to the Core specification. The information which was
specific to the HTTP rendering will reappear in that document when it is
completed.

I put some effort into describing how to extend OCCI Core so each base
type now has its on subsection describing the rules for domain-specific
extensions.

Comments welcome.

regards, Ralf

[1]
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels
[2]
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Infrastructure
_______________________________________________
occi-wg mailing list

occi-wg@ogf.org<mailto:occi-wg@ogf.org>

http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg