Previous section.

Systems Management: Common Information Model (CIM)
Copyright © 1998 The Open Group

Managed Object Format Components


All keywords in the MOF syntax are case-insensitive.


Comments can appear anywhere in MOF syntax and are indicated by either a leading double slash "//", or a pair of matching "/*" and "*/" sequences.

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

Semantic validation of a MOF specification involves an explicit or implied namespace context. This is defined as the namespace against which the objects in the MOF specification are validated and the namespace in which they are created. Multiple namespaces typically indicate the presence of multiple management spaces or multiple devices.

Naming of Schema Elements

This section describes the rules for naming of schema elements. This applies to classes, properties, qualifiers, methods and namespaces.

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

A class is an object describing a grouping of data items that are conceptually related and thought of as modeling an object. Class definitions provide a type system for instance construction.

Declaring a Class

A class is declared by specifying each of the following components:

  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); };


To indicate that a class is a subclass of another class, the derived class is declared by using a colon followed by the superclass name.

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

Any properties in a class definition can have default initializers. For example:
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

Qualifiers are metadata about a property, method, method parameter, class, or instance and are not part of the definition itself. For example, a qualifier is used to indicate whether a property value is modifiable (using the WRITE qualifier). Qualifiers always precede the declaration to which they apply.

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.


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; };

Parameter Interpretation Default
EnableOverride The qualifier is overridable yes
DisableOverride The qualifier cannot be overriden no
ToSubclass The qualifier is inherited by any subclass yes
Restricted The qualifier applies only to the class in which it is declared no
Translatable Indicates the value of the qualifier can be specified in multiple locales (language and country combination). When Translatable(yes) is specified for a qualifier, it is legal to create implicit qualifiers of the form:

where "label" is the name of the qualifier with Translatable(yes), and ll and cc are the language code and country code designation, respectively, for the translated string. In other words, a label_ll_cc qualifier is a clone, or derivative, of the "label" qualifier with a postfix to capture the translated value's locale. The locale of the original value (that is, the value specified using the qualifier with a name of "label") is determined by the locale pragma.

When a label_ll_cc qualifier is implicitly defined, the values for the other flavor parameters are assumed to be the same as for the "label" qualifier. When a label_ll_cc qualifier is defined explicitly, the values for the other flavor parameters must also be the same. A "yes" for this parameter is only valid for string-type qualifiers.

If an English description is translated into Mexican Spanish, the actual name of the qualifier is: DESCRIPTION_es_MX.


Table: Qualifier Flavors for Keyword Parameters

Key Properties

Instances of a class require some mechanism through which the instances can be distinguished within a single namespace. Designating one or more properties with the reserved qualifier "key" provides instance identification.

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

Qualifiers may be declared using the keyword "qualifier". The declaration of a qualifier allows the definition of types, default values, propagation rules (also known as Flavors), and restrictions on use.

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

Instances are declared using the keyword sequence "instance of" and the class name. The properties of the instance may be initialized within an initialization block.

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

An alias can be assigned to an instance using the following syntax:
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

Object references are properties which are links or pointers to other objects (classes or instances). The value of an object reference is a string, which represents a path to another object. The path includes:

  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:

UML MIN MAX Required MOF Text* Description
* 0 NULL Many
1..* 1 NULL Min(1) At least one
1 1 1 Min(1), Max(1) One
0,1 (or 0..1) 0 1 Max(1) At most one

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


Arrays of any of the basic data types can be declared in the MOF specification by using square brackets after the property identifier. Fixed-length arrays indicate their length as an unsigned integer constant within the square brackets; otherwise, the array is assumed to be variable length. Arrays can be bags, ordered lists or indexed arrays. An array's type is defined by the ARRAYTYPE qualifier, whose values are BAG, ORDERED or INDEXED. The default array type is BAG.

Regarding each of the array types:

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

A method is defined as an operation together with its signature. The signature consists of a possibly empty list of parameters and a return type. There are no restrictions on the type of parameters other than they must be one of the data types described in Section 2.2, a fixed or variable length array of one of those types, or be an object reference. Return types must be one of the data types described in Property Data Types . Return types cannot be arrays, but otherwise are unrestricted. Syntactically, the only thing that distinguishes a method from a property is the parameter list. The fact that methods are expected to have side-effects is outside the scope of this specification.

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

Compiler directives are provided as the keyword pragma, preceded by a hash (#) character, and followed by a string parameter.

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

Complier Directive Interpretation
#pragma namespace() Determines the current default namespace.
#pragma source() Defined in Chapter 5.
#pragma nonlocal() Defined in Chapter 5.
#pragma include() Has a file name as a parameter. The file is assumed to be a MOF file. The pragma has the effect of textually inserting the contents of the include file at the point where the include pragma is encountered.
#pragma locale() Declares the locale used for a particular MOF file. The locale is specified as a parameter of the form ll_cc, where ll is the language code based on ISO/IEC 639, and cc is the country code based on ISO/IEC 3166. When the pragma is not specified, the assumed locale is "en_US".

It is important to note that this pragma does not apply to the syntax structures of MOF. Keywords, such as "class" and "instance", are always in en_US.

#pragma instancelocale() Declares the locale used for instances described in a MOF file. This pragma specifies the locale when "INSTANCE OF" MOF statements include string or char16 properties, and the locale is not the same as the locale specified by a #pragma locale() statement. The locale is specified as a parameter of the form ll_cc where ll is the language code based on ISO/IEC 639, and cc is the country code based on ISO/IEC 3166.

Table: Standard Compiler Directives

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

The constant types supported in the MOF syntax are described in the subsections that follow. These are used in initializers for classes and instances, and in the parameters to named qualifiers.

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

String Constants

A string constant is a sequence of zero or more UCS-2 characters enclosed in double-quotes ("). A double-quote is allowed within the value as long as it is preceded immediately by a backslash (\).

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

Character and wide-character constants are specified as follows:
"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

Integer constants may be either decimal, binary, octal or hexadecimal. For example, the following are all legal:
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

Floating point constants are declared as specified by the IEEE in ANSI/IEEE Std 754-1985 (see Referenced Documents).

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

Object references are simple URL-style links to other objects (which may be classes or instances). They take the form of a quoted string containing an object path. The object path is a combination of a namespace path and the model path.

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.


All types can be initialized to the predefined constant NULL, which indicates no value has been provided at all. The details of the internal implementation of the NULL value are not mandated by this document.


Initializers are used both in class declarations for default values, and instance declarations to initialize a property to a value. The format of intializer values is as specified in Value Constants . The initializer value must match the property data type (the only exception is the NULL value, which may be used for any data type).

Initializing Arrays

Arrays can be defined to be of type, Bag, Ordered or Indexed, and can be initialized by specifying their values in a comma-separated list (as in the C programming language). The list is delimited with braces { }.

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 = { "", "", "" }; // 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

Aliases are symbolic references to an object located elsewhere in the MOF specification. They only have significance within the MOF specifiation in which they are defined, and are only used at compile time to facilitate establishment of references. They are not available outside of the MOF specification.

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.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index