Managed Object Format Components

Keywords

Comments

A "//" comment is terminated by an EOL or by the end of the MOF specification (whichever comes first).

For example:

 

// This is a comment

A "/*" comment is terminated by the next "*/" sequence, or by the end of the MOF specification (whichever comes first). Comments are not recognized by the metamodel and as such will not be preserved across compilations, that is, the output of a MOF compilation is not required to include any comments.

Validation Context

Naming of Schema Elements

CIM is a conceptual model that is not bound to a particular implementation. This allows it to be used to exchange management information in a variety of ways, examples of which are described in Four Ways to Use CIM . Some implementations may use case-sensitive technologies, while others may use case-insensitive technologies. The naming rules defined in this section are chosen to allow efficient implementation in either environment, and to enable the effective exchange of management information between all compliant implementations.

All names are case insensitive, in that two schema item names are identical if they differ only in case. This is mandated so that scripting technologies that are case insensitive can leverage CIM technology. (Note however that string values assigned to properties and qualifiers are not covered by this rule, and should be treated in a case-sensitive manner.)

The case of a name is set by its defining occurrence and must be preserved by all implementations. This is mandated so that implementations can be built using case-sensitive technologies such as Java and object databases. (This also allows names to be consistently displayed using the same user-friendly mixed-case format).

For example, an implementation, if asked to create class "Disk", must reject the request if there is already a class "DISK" in the current schema. Otherwise, when returning the name of the class "Disk", it must return the name in mixed case as it was originally specified.

CIM does not currently require support for any particular query language. It is assumed that implementations will specify which query languages are supported by the implementation and will adhere to the case conventions that prevail in the specified language. That is, if the query language is case-insensitive, statements in the language will behave in a case-insensitive manner.

For the full rules for schema names, see UNICODE Usage .

Class Declarations

Declaring a Class

1. The qualifiers of the class. This may be empty, or a list of qualifier name/value bindings separated by commas "," and enclosed with square brackets ("[" and "]").

2. The class name.

3. The name of the class from which this is derived (if any).

4. The class properties, which define the data members of the class. A property may also have an optional qualifier list, expressed in the same way as the class qualifier list. In addition a property has a data type, and (optionally) a default (initializer) value.

5. The methods supported by the class. A method has a signature consisting of its return type plus its parameters and their type and usage.

The following sample shows how to declare a class:

 

          [abstract]
class Win32_LogicalDisk
{
          [read] 
    string DriveLetter;
          [read, Units(“kilo byes”)] 
    sint32 RawCapacity     =     0;
          [write] 
    string VolumeLabel;
           [Dangerous]
    boolean Format(IN bool FastFormat);
};

Subclasses

For example, if the class "Acme_Disk_v1" is derived from the class "CIM_Media":

 

class Acme_Disk_v1 : CIM_Media
{
    // Body of class definition here ...
};

The terms Base class, Superclass and Supertype are used interchangeably, as are Derived class, Subclass and Subtype.

The Superclass declaration must appear at a prior point in the MOF specification or already be a registered class definition in the namespace in which the derived class is defined.

Default Property Values

 

class Acme_Disk_v1 : CIM_Media
{
    string Manufacturer    =     "Acme";
    string ModelNumber     =     "123-AAL";
};

When new instances of the class are declared, then such a property is automatically assigned its default value unless the instance declaration explicitly assigns a value to the property.

Class and Property Qualifiers

Certain qualifiers are well known and cannot be redefined (see the description of the metaschema). Apart from these, arbitrary qualifiers may be used.

Qualifier declarations include an explicit type indicator, which must be one of the intrinsic types. A qualifier with an array-based parameter is assumed to have a type, which is a variable-length homogeneous array of one of the intrinsic types. Note that in the case of boolean arrays, each element in the array is either TRUE or FALSE.

Examples:

 

Write(true)                                // boolean            
profile { true, false, true }              // boolean []
description("A string")                    // string
info { "first", "second", "third" }        // string []
id(12)                                     // sint32
idlist { 21, 22, 40, 43 }                  // sint32 []
apple(3.14)                                // real32
oranges { -1.23E+02, 2.1 }                 // real32 []

Qualifiers are applied to a class by preceding the class declaration by a qualifier list, comma-separated, and enclosed within square brackets. Qualifiers are applied to a property in a similar fashion.

For example:

 

class CIM_Process:CIM_LogicalElement
{
    uint32 Priority;
        Write(true)]
    string Handle;
};

Qualifiers can be automatically propagated from classes to derived classes, or from classes to instances subject to certain rules. The rules behind how the propagation occurs are attached to each qualifier and encapsulated in the concept of the qualifier flavor. For example, a qualifier may be designated in the base class as automatically propagating to all of its derived classes, or the qualifier could be designated as belonging specifically to that class and not to be propagated. This aspect of the flavor is referred to as the propagation rule. In addition, the qualifier flavor can be used to control whether or not derived classes can be override the qualifier value, or whether it must be fixed for an entire class hierarchy. This aspect of qualifier flavor is referred to as override permissions.

Qualifier flavors are indicated by an optional clause after the qualifier and preceded by a colon. They consist of some combination of the key words EnableOverride, DisableOverride, ToSubclass and Restricted, indicating the applicable propagation and override rules. The recognized flavor types are listed in Qualifier Flavors for Keyword Parameters .

For example:

 

class CIM_Process:CIM_LogicalElement
{
   uint32 Priority;
       [Write(true):DisableOverride ToSubclass]
   string Handle;
};

In this example, Handle is designated as writable for the Process class and for every subclass of this class.

When specifying a boolean qualifier in a class or property declaration, the name of the qualifier can be used without also specifying a value. From the previous example:

 

class CIM_Process:CIM_LogicalElement
{
    uint32 Priority;
        [Write]      // Equivalent declaration to Write (True)
    string Handle;
};

If only the qualifier name is listed for a boolean qualifier, it is implicitly set to TRUE.

In contrast, when a qualifier is not specified at all for a class or property, the default value for the qualifier is assumed. Using another example:

 

        [Association, 
        Aggregation]       // Specifies the Aggregation qualifier 
                           // to be True 
class CIM_SystemDevice: CIM_SystemComponent
{
        [Override ("GroupComponent"),
        Aggregate] // Specifies the Aggregate qualifier to be True 
    CIM_ComputerSystem Ref GroupComponent;
        [Override ("PartComponent"), 
        Weak]      // Defines the Weak qualifier to be True
    CIM_LogicalDevice Ref PartComponent;
};

        [Association]      // Since the Aggregation qualifier 
                           // is not specified, its default value, 
                           // False, is set
class Acme_Dependency: CIM_Dependency
{
        [Override ("Antecedent")]   // Since the Aggregate and Weak 
                           // qualifiers are not used, their default 
                           // values, False, are assumed
    Acme_SpecialSoftware Ref Antecedent;
        [Override ("Dependent")]
    Acme_Device Ref Dependent;
};

Key Properties

For example, the following class has one property ("Volume") which serves as its key.

 

class Acme_Drive
{
        [key] string Volume;
    string FileSystem;
    sint32 Capacity;
};

In this case, instances of "Drive" are distinguished using the "Volume" property, which acts as the key for the class.

Compound keys are supported and are designated by marking all of the required properties with the key qualifier.

If a new subclass is defined from a superclass, and the superclass has key properties (including those inherited from other classes), the new subclass cannot define any additional key properties. New key properties in the subclass can be introduced only if all classes in the inheritance chain of the new subclass are keyless.

If any reference to the class has the Weak qualifier, the properties that are qualified as Key in the other classes in the association are propagated to the referenced class. The key properties are duplicated in the referenced class using the name of the property, prefixed by the name of the original declaring class. For example:

 

class CIM_System:CIM_LogicalElement
{
        [Key]
    string Name;
};

class CIM_LogicalDevice: CIM_LogicalElement
{
        [Key]
    string DeviceID;
        [Key, Propagated("CIM_System.Name")]
    string SystemName;
};

[Association]
class CIM_SystemDevice: CIM_SystemComponent
{
        [Override ("GroupComponent"), Aggregate, Min(1), Max(1)]
    CIM_System Ref GroupComponent;
        [Override ("PartComponent"), Weak]
    CIM_LogicalDevice Ref PartComponent;
};

Qualifier Declarations

The default value for a declared qualifier is used when the qualifier is not explicitly specified for a given schema element (explicit specification includes when the qualifier specification is inherited).

The MOF syntax allows specifying a qualifier without an explicit value. In this case, the assumed value depends on the qualifier type: booleans are true, numeric types are null, strings are null and arrays are empty.

For example the alias qualifier is declared as follows:

 

qualifier alias : string = null, scope (property, reference, method);

This declaration establishes a qualifier called alias. The type of the qualifier is string. It has a default value of null and may only be used with properties, references and methods.

The metaqualifiers are declared as follows:

 

Qualifier Association : boolean = false, 
    Scope(class, association), Flavor(DisableOverride);

Qualifier Indication : boolean = false, 
    Scope( class, indication), Flavor(DisableOverride);

See CIM Metaschema for the complete list of standard qualifiers.

Instance Declarations

Property initialization consists of an optional list of preceding qualifiers, the name of the property and an optional value. Any properties not initialized will receive their default values as specified in the class definition, or (if no default value has been specified) the special value NULL to indicate "absence of value". For example, given the class definition:

 

class Acme_LogicalDisk
{
        [key]
    string DriveLetter;
        [Units("kilo bytes")]
    sint32 RawCapacity   =   128000;
        [write]
    string  VolumeLabel;
        [Units("kilo bytes")]
    sint32 FreeSpace;
};

then an instance of the above class might be declared as follows:

 

instance of Acme-LogicalDisk
{
    DriveLetter = "C";
    VolumeLabel = "myvol";
};

The resultant instance would take the following property values:

1. "DriveLetter" would be assigned the value "C".

2. "RawCapacity" would be assigned the default value 128000.

3. "VolumeLabel" would be assigned the value "myvol".

4. "FreeSpace" would be assigned the value NULL.

For subclasses, all of the properties in the superclass must be initialized along with the properties in the subclass. Any properties not specifically assigned in the instance block will receive either the default value for the property if there is one, or else the value NULL (if there is not one).

The values of all key properties must be specified in order for an instance to be identified and created. There is no requirement to explicitly initialize other properties. See NULL on behavior when there is no property initialization.

Instances of Associations may also be defined, for example:

Instance of CIM_ServiceSAPDependency
{
  Dependent = "cim://root/default/Service.Name = \"mail\"";
  Antecedent = "cim://root/default/ServiceAccessPoint.Name = \"PostOffice\"";
}

Instance Aliasing

 

instance of Acme_LogicalDisk as $Disk
{
    // Body of instance definition here ...
};

Such an alias can later be used within the same MOF specification as a value for an object reference property. For more information, see Initializing References using Aliases .

Object References

1. The namespace in which the object resides

2. The class name of the object

3. If the object represents an instance, the values of all key properties for that instance

Object reference properties are declared by "XXX ref", indicating a strongly typed reference to objects of the class with name "XXX" (or a derived class thereof).

For example:

 

        [Association]
class Acme_ExampleAssoc
{
    Acme_AnotherAssoc ref Inst1;

    Acme_Aclass ref Inst2;
};

In associations, object references have cardinalities - denoted using MIN and MAX qualifiers. Here are examples of UML cardinality notations and their respective combinations of MIN and MAX values:

See also Initializing References using Aliases , on Initializing References Using Aliases.

Arrays

Regarding each of the array types:

• An array of type BAG is unordered and multi-valued, allowing duplicate entries.
  

• An ordered list (ORDERED) is a special case of a bag, which is multi-valued and allows duplicate entries. It returns the property values in an implementation dependent, but fixed order.

• An indexed array (INDEXED) maintains the order of the elements, and could be implemented based on an integer index for each of the array values.

Note that for the Bag array type, no significance is defined for the array index other than a convenience for accessing the elements of the array. For example, there can be no assumption that the same index will return the same value for every access to the array. The only assumption is that a complete enumeration of the indices will return a complete set of values.

For the Ordered array type, the array index is significant as long as no array elements are added, deleted or changed. In this case the same index will return the same value for every access to the array. If an element is added, deleted or changed, the index of the elements might change according to the implementation-specific ordering algorithm.

The Indexed array maintains the correspondence between element position and value. Array elements can be overwritten, but not deleted.

This version of the CIM specification does not support n-dimensional arrays.

Arrays of any basic data type are legal. Arrays of references are not legal. Arrays must be homogeneous. Arrays of mixed types are not supported. In MOF, the data type of an array precedes the array name. Array size, if fixed length, is declared within square brackets, following the array name. If a variable length array is to be defined, empty square brackets follow the array name.

Arrays are declared using the following MOF syntax:

 

class A
{
  [Description("An indexed array of variable length"), ArrayType("Indexed")]
  uint8 MyIndexedArray[];

  [Description("A bag array of fixed length")]
  uint8 MyBagArray[17];
};

If default values are to be provided for the array elements, the following syntax is used:

 

class A
{
  [Description("A bag array property of fixed length")]
  uint8 MyBagArray[17] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17};
};

The following MOF presents further examples of Bag, Ordered and Indexed array declarations:

 

class Acme_Example
{
    char16 Prop1[];         // Bag (default) array of chars, Variable length

    [ArrayType ("Ordered")] // Ordered array of double-precision reals,
    real64 Prop2[];         // Variable length 

    [ArrayType ("Bag")]     // Bag array containing 4 32-bit signed integers
    sint32 Prop3[4]; 

    [ArrayType ("Ordered")] // Ordered array of strings, Variable length
    string Prop4[] = {"an", "ordered", "list"};

        // Prop4 is variable length with default values defined at the
        // first three positions in the array

    [ArrayType ("Indexed")] // Indexed array of 64-bit unsigned integers 
    uint64 Prop5[];
};

Method Declarations

In the following example, Start and Stop methods are defined on the Service class. Each method returns an integer value:

 

class CIM_Service:CIM_LogicalElement
{
        [Key]
    string  Name;
    string  StartMode;
    boolean Started;

    uint32  StartService();
    uint32  StopService();
};

In the following example, a Configure method is defined on the Physical DiskDrive class. It takes a DiskPartitionConfiguration object as a parameter and returns a boolean value:

 

class Acme_DiskDrive:CIM_Media
{
    sint32  BytesPerSector;
    sint32  Partitions;
    sint32  TracksPerCylinder;
    sint32  SectorsPerTrack;
    string  TotalCylinders;
    string  TotalTracks;
    string  TotalSectors;
    string  InterfaceType;
    boolean Configure([IN] DiskPartitionConfiguration REF config);
};

Compiler Directives

The current standard compiler directives are listed in the following table:

Additional pragma directives may be added as a MOF extension mechanism. Unless standardized in a future CIM specification, such new pragma definitions must be considered vendor-specific. Use of non-standard pragmas will affect interoperability of MOF import and export functions.

When a qualifier value is derived from either a qualifier or a pragma, the qualifier overrides the pragma.

Value Constants

A formal specification of the representation may be found in MOF Syntax Grammar Description .

String Constants

For example:

 

"This is a string"

Successive quoted strings are concatenated as long as only white space or a comment intervenes:

 

"This" "becomes a long string"
"This" /* comment */ "becomes a long string"

The escape sequences \n, \t, and \r are recognized as legal characters within a string.

The complete set is:

 

\b        // \x0008: backspace BS
\t        // \x0009: horizontal tab HT
\n        // \x000A: linefeed LF
\f        // \x000C: form feed FF
\r        // \x000D: carriage return CR
\"        // \x0022: double quote "
\'        // \x0027: single quote '
\\        // \x005C: backslash \
\x<hex>   // where <hex> is one to four hex digits
\X<hex>   // where <hex> is one to four hex digits 

The character set of the string depends on the character set supported by the local installation. While the MOF specification may be submitted in UCS-2 form (see UCS Transformation Format-8 - UTF-8 in Referenced Documents), the local implementation may only support ANSI, and vice-versa. Therefore, the string type is unspecified and dependent on the character set of the MOF specification itself. If a MOF specification is submitted using UCS-2 characters outside of the normal ASCII range, then the implementation may have to convert these characters to the locally equivalent character set.

Character Constants

 

"a"
"\en"
"1"
"\x32"

Note that trigraphs such as \020 are not supported.

Integer values can also be used as character constants, as long as they are within the numeric range of the character type. For example, wide-character constants must fall within the range 0 to 0xFFFF.

Integral Constants

 

1000
-12310
0x100
01236
100101B

Note that binary constants have a series of 1 and 0 digits, with a "b" or "B" suffix to indicate that the value is binary.

The number of digits permitted depends on the current type of the expression. For example, it is not legal to assign the constant 0xFFFF to a property of type uint8.

Floating-Point Constants

For example, the following are legal:

 

3.14
-3.14
-1.2778E+02

The range for floating point constants depends on whether float or double properties are used and must fit within the range specified for IEEE 4-byte and 8-byte floating point values, respectively.

Object Ref Constants

For example:

 

"//./root/default:LogicalDisk.SystemName=
"//./root/default:NetworkCard=2"

An object reference can also be an alias. See Initializing References using Aliases for more details.

NULL

Initializers

Initializing Arrays

For example, given the class definition:

 

class Acme_ExampleClass 
{
    [ArrayType ("Indexed")]
    string ip_addresses [];    // Indexed array of variable length
    sint32 sint32_values [10]; // Bag array of fixed length = 10
};

then a valid instance declaration is:

 

instance of Acme_ExampleClass
{
    ip_addresses = { "1.2.3.4", "1.2.3.5", "1.2.3.7" };

        // ip_address is an indexed array of at least 3 elements, where 
        // values have been assigned to the first three elements of the
        // array

    sint32_values = { 1, 2, 3, 5, 6 };
};

Refer to Arrays for additional information on declaring arrays, and the distinctions between bags, ordered arrays and indexed arrays.

Initializing References using Aliases

Classes and instances may be assigned an alias in the manner described in Instance Aliasing .

Aliases are identifiers which begin with the "$" symbol. When a subsequent reference to that instance is needed for an object reference property, the identifier is used in place of an explicit initializer.

Assuming that $Alias1 and $Alias2 have been declared as aliases for instances, and the obref1 and obref2 properties are object references, this example shows how the object references could be assigned to point to the aliased instances:

 

instance of Acme_AnAssociation
{
    strVal = "ABC";
    obref1 = $Alias1;
    obref2 = $Alias2;
};

Forward-referencing and circular aliases are permitted.