Here are some ideas for extending the description of attributes. To more clearly specify attributes, a new new class 'attribute' should be added to OCCI Core. For the class diagram this would require to remove '+ attributes :Set<String>' from category and instead connect it with the attribute class in a many to one dependency. Ideas for the attribute class: - the attribute class should consist of the attributes: mutable, required, type, default - the naming of attributes of the OCCI specification MUST start with occi followed by term and the attribute name (e.g. occi.compute.cores) - the naming of attributes of user defined mixins MUST start with the reversed domain name of the mixin scheme followed by the term and the attribute name (e.g. com.example.my_mixin.my_attribute) - the attribute type should contain restrictions on the attribute like for example: * string: choices, min_length, max_length * number: bounds (one or more lower and upper bounds) - there might be more detailed attribute types such as URL or URI, float, integer, ... --Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
On Sun, 11 Mar 2012 18:35:51 +0000, "Feldhaus, Florian" <florian.feldhaus@gwdg.de> wrote:
Here are some ideas for extending the description of attributes. To more clearly specify attributes, a new new class 'attribute' should be added to OCCI Core. For the class diagram this would require to remove '+ attributes :Set<String>' from category and instead connect it with the attribute class in a many to one dependency.
We actually had an Attribute class for I while and I guess it is time to re-introduce it. However, we MUST NOT call it "Attribute". First we already have like 5 or so different things we call "attribute" currently and adding another "thing" with the same name is just too much. OCCI Core is hard enough to read as it is already. Secondly, an object of this class is not really an attribute since it has no value. It is a type definition of an attribute, a meta-attribute :D But given a proper name which is not too confusing this is all great.
Ideas for the attribute class: - the attribute class should consist of the attributes: mutable, required, type, default
hehe, attribute class with attributes... you see why we need another name? ;)
- the naming of attributes of the OCCI specification MUST start with occi followed by term and the attribute name (e.g. occi.compute.cores)
No, this is too restrictive. Remember that each scheme is a separate namespace. What we could do is say that attribute name must end with .term.attrname, e.g. occi.[xxx.]<term>.<attr>.
- the naming of attributes of user defined mixins MUST start with the reversed domain name of the mixin scheme followed by the term and the attribute name (e.g. com.example.my_mixin.my_attribute)
See above, same applies here.
- the attribute type should contain restrictions on the attribute like for example: * string: choices, min_length, max_length * number: bounds (one or more lower and upper bounds) - there might be more detailed attribute types such as URL or URI, float, integer, ...
This must be detailed out properly. I would rather keep it on the simple side though... /Ralf
--Florian
-------------------------------------------------------------------------------
GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de
-----------------------------------------------------------------------------------
Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598
-----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
I think we could fix ourselves to the following normative namespaces: occi.core.* for attributes from the core model occi.infrastructure.* for attributes from the infrastructure model and com.example.* for our examples. These three MUST NOT be used by third-party extensions; instead, third-party extensions SHOULD follow the reverse-domain-name pattern to prefix their attributes. Re: simple I would second what Ralf says. Properly implementing a type system is a non-trivial task. -A. Am 14.03.2012 um 09:22 schrieb Ralf Nyren:
On Sun, 11 Mar 2012 18:35:51 +0000, "Feldhaus, Florian" <florian.feldhaus@gwdg.de> wrote:
Here are some ideas for extending the description of attributes. To more clearly specify attributes, a new new class 'attribute' should be added to OCCI Core. For the class diagram this would require to remove '+ attributes :Set<String>' from category and instead connect it with the attribute class in a many to one dependency.
We actually had an Attribute class for I while and I guess it is time to re-introduce it.
However, we MUST NOT call it "Attribute". First we already have like 5 or so different things we call "attribute" currently and adding another "thing" with the same name is just too much. OCCI Core is hard enough to read as it is already. Secondly, an object of this class is not really an attribute since it has no value. It is a type definition of an attribute, a meta-attribute :D
But given a proper name which is not too confusing this is all great.
Ideas for the attribute class: - the attribute class should consist of the attributes: mutable, required, type, default
hehe, attribute class with attributes... you see why we need another name? ;)
- the naming of attributes of the OCCI specification MUST start with occi followed by term and the attribute name (e.g. occi.compute.cores)
No, this is too restrictive. Remember that each scheme is a separate namespace. What we could do is say that attribute name must end with .term.attrname, e.g. occi.[xxx.]<term>.<attr>.
- the naming of attributes of user defined mixins MUST start with the reversed domain name of the mixin scheme followed by the term and the attribute name (e.g. com.example.my_mixin.my_attribute)
See above, same applies here.
- the attribute type should contain restrictions on the attribute like for example: * string: choices, min_length, max_length * number: bounds (one or more lower and upper bounds) - there might be more detailed attribute types such as URL or URI, float, integer, ...
This must be detailed out properly. I would rather keep it on the simple side though...
/Ralf
--Florian
-------------------------------------------------------------------------------
GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de
-----------------------------------------------------------------------------------
Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598
-----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
On Wed, 14 Mar 2012 11:39:33 +0000, <alexander.papaspyrou@tu-dortmund.de> wrote:
I think we could fix ourselves to the following normative namespaces:
occi.core.* for attributes from the core model
+1
occi.infrastructure.* for attributes from the infrastructure model
Would require renaming all attributes in OCCI Infrastructure...
and
com.example.* for our examples.
+1 for consistent naming of attributes in our examples!
These three MUST NOT be used by third-party extensions; instead, third-party extensions SHOULD follow the reverse-domain-name pattern to prefix their attributes.
I like the whole occi.* namespace to be reserved for future OCCI spec usage (as currently specified in OCCI Core). Otherwise I agree. /Ralf
Re: simple I would second what Ralf says. Properly implementing a type system is a non-trivial task.
-A.
Am 14.03.2012 um 09:22 schrieb Ralf Nyren:
On Sun, 11 Mar 2012 18:35:51 +0000, "Feldhaus, Florian" <florian.feldhaus@gwdg.de> wrote:
Here are some ideas for extending the description of attributes. To
more
clearly specify attributes, a new new class 'attribute' should be added to OCCI Core. For the class diagram this would require to remove '+ attributes :Set<String>' from category and instead connect it with the attribute class in a many to one dependency.
We actually had an Attribute class for I while and I guess it is time to re-introduce it.
However, we MUST NOT call it "Attribute". First we already have like 5 or so different things we call "attribute" currently and adding another "thing" with the same name is just too much. OCCI Core is hard enough to read as it is already. Secondly, an object of this class is not really an attribute since it has no value. It is a type definition of an attribute, a meta-attribute :D
But given a proper name which is not too confusing this is all great.
Ideas for the attribute class: - the attribute class should consist of the attributes: mutable, required, type, default
hehe, attribute class with attributes... you see why we need another name? ;)
- the naming of attributes of the OCCI specification MUST start with occi followed by term and the attribute name (e.g. occi.compute.cores)
No, this is too restrictive. Remember that each scheme is a separate namespace. What we could do is say that attribute name must end with .term.attrname, e.g. occi.[xxx.]<term>.<attr>.
- the naming of attributes of user defined mixins MUST start with the reversed domain name of the mixin scheme followed by the term and the attribute name (e.g. com.example.my_mixin.my_attribute)
See above, same applies here.
- the attribute type should contain restrictions on the attribute like for example: * string: choices, min_length, max_length * number: bounds (one or more lower and upper bounds) - there might be more detailed attribute types such as URL or URI, float, integer, ...
This must be detailed out properly. I would rather keep it on the simple side though...
/Ralf
--Florian
GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de
Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
On Mar 14, 2012, at 2:45 PM, Ralf Nyren wrote:
These three MUST NOT be used by third-party extensions; instead, third-party extensions SHOULD follow the reverse-domain-name pattern to prefix their attributes.
I like the whole occi.* namespace to be reserved for future OCCI spec usage (as currently specified in OCCI Core). Otherwise I agree.
Procedure for Registration of Subnamespace Identifiers in the URN:OGF Hierarchy http://ogf.org/documents/GFD.191.pdf Alan
participants (4)
-
Alan Sill -
alexander.papaspyrou＠tu-dortmund.de -
Feldhaus, Florian -
Ralf Nyren