1) I believe we need a definition for attributes in the document... The definition needs to qualify the role of attributes and properties of
On Tue, 7 Aug 2012 07:48:35 +0000, "Feldhaus, Florian" the
attributes.
I fully agree and I would like to see the definition of attributes and attribute properties in OCCI Core.
2) Differentiate between OCCI Resource attributes and Attributes defined by Mixins.
That's right. I'm not entirely sure how to describe attributes and attribute properties. Both have a name (e.g. 'occi.core.title') and a value. The value for Attributes associated with Entities can be of type String, Number and Boolean (e.g. base types). For Attribute Properties
+1 In OO terminology OCCI Resource and OCCI Link are just plain classes. These classes (and their sub-classes) can have a bunch of attributes. Each _attribute_ of an object instantiated from one of these classes has: - A name - A value - A type (hopefully) Just basic OO, nothing fancy. Category/Kind/Mixin is a mechanism to describe what the OCCI Resource/Link classes look like. It is like a crude form of machine readable UML. The tricky part is that Category/Kind/Mixin are also modelled as classes to create a Core model which is relatively easy to implement. Today, the Category/Kind/Mixin mechanism does only tell you the _name_ of the attributes to be found in OCCI Resource/Link. The minimal addition would be to also describe the type, mutability and default-value of attributes. This is what is currently called "attribute properties" in OCCI HTTP Rendering. the
value contain the attribute properties (e.g. Type, Description, …). If we can put this into a class diagram, we IMHO have a good way to describe attributes and attribute properties.
3) Mixins may reference attributes defined in external schemas, DMTF's CIM for example. We need a way to filter attributes sourced from external schemas and hopefully not overload OCCI clients, servers or other information management vehicles (ie templates). This capability may also be required for the converse case, identifying attributes that will be used, all other will be ignored. This use case may also valid for OCCI Resource defined attributes.
It took some time for me to understand how this could be realized. Referencing attributes defined in external schemas can bring many
due to different ways of handling the attributes and currently this is not supported by OCCI. In my opinion, all attributes which are used within
We have to be careful what we mean here. Real attributes as part of an OCCI Resource/Link sub-class or the _description_ of those attributes found in Category/Kind/Mixin. There is really no difference between attributes described by Kind or Mixin. They are on the same level. Kind describes attributes which always are present in an OCCI Resource/Link sub-class. Mixin describes attributes which availability may change at run-time. How you decide to implement attributes in your OCCI Resource/Link classes is up to you. It does not matter if you use native class attributes or a hash table. problems the
OCCI context need to be described using OCCI. Implementations can not be required to understand all kinds of external schemas. We may come up with a transformation between external schemas and OCCI - for example an XSLT between CIM and OCCI. Then we can reference external schemas and an OCCI implementation can understand that schema using a translation. I strongly recommend to not touch this topic for the next iteration of the documents as this needs a lot more discussion and some proper examples how it could be used.
I agree with Florian here, let us keep it to: "all attributes which are used within the OCCI context need to be described using OCCI." ... for the time being. regards, Ralf