(8/5/2009 3:53 PM
): Added to CIM issues list as issue #1259.
(6/12/2009 4:28 PM
): I like the idea of making implemenations easier and better and this suggestion moves us toward that at a small price of implemenation artifacts not exactly matching SI standard names. I believe the enumeration documenation could use standard SI names and thus conform to the spirit of following SI. There are three related issues here that I see.
1) The SI units are not required to be specified in exchanges in almost all cases. Only in the case that an attribute can take on multiple types would we need a type that would exchange the SI units. For example, Domain::ActivePower need never exchange the "W" as UnitSymbol, it is always implied and might as well just be documented.
2) The handling of these units as enumerations is problematic for combinations of units. Do we specify enumeration values for each possible combination? Seems ugly.
3) We have no way to distinquish between logical enumerations were we have a documented meaning and invent a CIM enumeation value name, and cases where we have a String value that we want restricted to a subset of values. The latter case seems more of the situation when wanting to explicitly exchange the official SI units. We probaly need a more general attribute (or association) constraint capability like the OMG's OCL (object constaint language) to handle these cases.
I would be in favor of naming restrictions on enumeration values so implemenations like Java (and many others) can more direclty use CIM. We have precedence in restricting CIM class, attriute, and association names and I believe we would benefit from this approach when applied to enumerations as well.
My preference would be to enforce the enumeration value naming as suggested, remove UnitSymbol from the Domain types except for the "variable" types, add the SI units to the documenation of types so semantics are clear and SI based, change UnitSymbol into a Domain::String, and add OCL to clarify how an attribute is constrained, or leave this to profing.
The suggested resolution is a reasonable short term fix that keeps implementations working and I doubt there is much existing software that depends upon the degree symbol. To my knowledge, the degree symbole has not been part of InterOp exchanges.
Enumeration values should be named like attribues (possibly relax the first character lower case rule but prefer lower case) and require all enumeation values to be unique for an enumeration, but not unique for a class where multiple enumerations could be composed and might have identical enumeration values like "default", "normal", "on", or simlar common states. There would be only a few minor changes to the existing CIM UML model to meet these naming rules.