[occi-wg] Attribute descriptions

[Feldhaus, Florian]

Hi,

Am 31.07.2012 um 07:48 schrieb Gary Mazz:

> Hi,
> 
> Sorry this took so long, had a family medical emergency which took up most of last half of week and the weekend.
> 
> There is one or two items about attributes that I believe needed to be clarified. As well as one or two items that are potential for conflicts. I listed them below, they will warrant  a discuss and vote to see which capability we would consider supporting.
> 
> 1) I believe we need a definition for attributes in the document... The definition needs to qualify the role of attributes and properties of 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 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 problems 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 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.

> 4) The OCCI server should have the ability to override attributes defined in external schemas and OCCI Resources. The overridden attributes warrants a discrete definition, not to confuse externally defined attributes with server defined attributes. These attributes may fall into the class of "calculated attributes".

See above. If there is a translation of the external schema into the world of OCCI, there is no problem with overriding attributes, as mixins are already allowed to do this.

> 5) Indicators: An Indicator is threshold based logic used to show whether a metric is operating within a set of limits. Indicators may be polled by the client using traditional client/server technologies or pushed to the client by the server through asynchronous methods.
> 
> What an indicator looks like is interesting.. we need to determine the following:
> 
> a) Do Indicators contain more then one threshold?
> b) Can Indicators send or trigger asynchronous  events, if yes, what does it look like ?
> c) Should each Indicator have a name ?
> c) How is MetricName/Indicator naming schema defined ? What does the canonical form look like ?

I'm not sure I properly understand what you mean with indicators. From my point of view we need a way to give indications on how attributes/metrics should or could be used and this is something we can do with the Attribute properties. There are three main properties (Type, Mutable, Required) which MUST be taken into account by implementations of OCCI. All other properties (e.g. Pattern, Default, Description, Minimum, Maximum, …) are only indicators on the limits of the attribute. These optional properties SHOULD be taken into account by implementations.

Does that meet your understanding of indicators or is it something completely different?

Cheers,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120807/bcd522e8/attachment.bin>