[occi-wg] Attribute descriptions

[Gary Mazz]

On 8/7/2012 1:48 AM, Feldhaus, Florian wrote:
> 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.
OCCI Core is a meta schema or a hyper schema. The purpose of this type 
of schema is to set the basic rules of for model entities, not details 
specific to an implementation. "OCCI Infrastructure" is an more 
appropriate level for defining resource and topology specific attributes.
>
>> 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.
The intent was to have a link back to the originating schema entity for 
the attribute... This become important if a broker needs to evaluate the 
origin of an attribute.
>
>> 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.
Well, this is already model supported in OCCI, however, I don't think 
any OCCI software has implemented the functionality. Since JSON does not 
have a viable schema, we have no way to transform foreign schemas into 
JSON.  This is an issue when referencing external systems ie CDMI.  We 
can define the foreign import and transform methods in the Mixin. We 
need to describe what that constraint looks like.
>> 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.
Yes, agreed. We still need to agree on a way to describe the intent and 
precedence. We currently do not have that behavior described in OCCI 
Core and Infrastructure.
>
>> 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?
I think we are overlaying semantics.
  In OCCI we have 3 levels of information, the meta schema (OCCI core), 
the schema (OCCI infrastructure) and the realization (OCCI instantiated 
topology).

Properties in the Realization are defined as "attributes" in the OCCI 
Infrastructure.  OCCI Infrastructure Attributes, as well as OCCI Core 
Attributes,  are described using  Attribute Properties (Type, Mutable, 
Required).  In the Realization, an Indicator is a Property of a Resource.

Like Metrics, Indicators are defined as OCCI Infrastructure Attributes. 
They represent an alternate unit of a Metric, much like float and 
integer. In one form a Metric can be a integer value. In the Indicator 
form, the Metric may be GOOD/FAIL enumerated value. However, Indicators 
have addition configuration information associated with them to describe 
the operating constraints of the Value and any other associated actions 
ie async events.

We should discuss if we want indicators and if we do, how realized 
values will be managed.

   gary

>
> Cheers,
> Florian