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. 2) Differentiate between OCCI Resource attributes and Attributes defined by Mixins. 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. 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". 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 ? cheers, gary
I think this is good input...indicators do look interesting (let the server do the work for you). Let's get this on the agenda/calendar to discuss further. Gary Mazz wrote:
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.
2) Differentiate between OCCI Resource attributes and Attributes defined by Mixins.
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.
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".
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 ?
cheers, gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
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
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
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
On 8/7/2012 1:48 AM, Feldhaus, Florian wrote: 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.
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
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. 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
participants (4)
-
Feldhaus, Florian -
Gary Mazz -
Michael Behrens -
Ralf Nyren