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