1.1 CIM Management Schema *

1.2 CIM Implementations *

2 Meta Schema *

2.1 Definition of the Meta Schema *

2.2 Property Data Types *

2.3 Supported Schema Modifications *

2.4 Class Names *

2.5 Qualifiers *

3 Managed Object Format *

3.1 MOF usage *

3.2 Class Declarations *

3.3 Instance Declarations *

4 MOF Components *

4.1 Keywords *

4.2 Comments *

4.3 Validation Context *

4.4 Naming of Schema Elements *

4.5 Class Declarations *

4.6 Association Declarations *

4.7 Qualifier Declarations *

4.8 Instance Declarations *

4.9 Method Declarations *

4.10 Compiler Directives *

4.11 Value Constants *

4.12 Initializers *

5 Naming *

5.1 Background *

5.2 Weak Associations: Supporting Key Propagation *

5.3 Naming CIM Objects *

5.4 Specifying Object Names in MOF Files *

6 Mapping Existing Models Into CIM *

6.1 Technique Mapping *

6.2 Recast Mapping *

6.3 Domain Mapping *

6.4 Mapping Scratch Pads *

7 Repository Perspective *

7.1 DMTF MIF Mapping Strategies *

7.2 Recording Mapping Decisions *

Appendix A MOF Syntax Grammar Description *

Appendix B CIM META SCHEMA *

Appendix C Values for UNITS Qualifier *

Appendix D UML Notation *

Appendix E Glossary *

Appendix F Unicode Usage *

F.1 MOF Text *

F.2 Quoted Strings *

Appendix G Guidelines *

G.1 Mapping of Octet Strings *

G.2 SQL Reserved Words *

Appendix H References *

2. Introduction and Overview

This section describes the many ways in which the Common Information Model (CIM) can be used. It provides a context in which the details described in the later chapters can be understood.

Ideally, information used to perform tasks is organized or structured to allow disparate groups of people to use it. This can be accomplished by developing a model or representation of the details required by people working within a particular domain. Such an approach can be referred to as an information model. An information model requires a set of legal statement types or syntax to capture the representation, and a collection of actual expressions necessary to manage common aspects of the domain (in this case, complex computer systems). Because of the focus on common aspects, the DMTF refers to this information model as CIM, the Common Information Model.

This document describes an object-oriented meta model based on the Unified Modeling Language (UML). This model includes expressions for common elements that must be clearly presented to management applications (for example, object classes, properties, methods and associations). This document does not describe specific CIM implementations, APIs, or communication protocols – those topics will be addressed in a future version of the specification. For information on the current core and common schemas developed using this meta model, contact the Distributed Management Task Force.

1. CIM Management Schema

1. Core Model

The Core model is a small set of classes, associations and properties that provide a basic vocabulary for analyzing and describing managed systems. The Core model represents a starting point for the analyst in determining how to extend the common schema. While it is possible that additional classes will be added to the Core model over time, major re-interpretations of the Core model classes are not anticipated.

2. Common Model

The Common model is a basic set of classes that define various technology-independent areas. The areas are systems, applications, networks and devices. The classes, properties, associations and methods in the Common model are intended to provide a view of the area that is detailed enough to use as a basis for program design and, in some cases, implementation. Extensions are added below the Common model in platform-specific additions that supply concrete classes and implementations of the Common model classes. As the Common model is extended, it will offer a broader range of information.

3. Extension Schema

1. CIM Implementations

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; four of these ways are illustrated in Figure 1-1. It is possible to use these ways in combination within a management application.



Figure -1 Four Ways to Use CIM

As a repository (see the Repository Perspective section for more detail), the constructs defined in the model are stored in a database. These constructs are not instances of the object, relationship, and so on; but rather are definitions for someone to use in establishing objects and relationships. The meta model used by CIM is stored in a repository that becomes a representation of the meta model. This is accomplished by mapping the meta-model constructs into the physical schema of the targeted repository, then populating the repository with the classes and properties expressed in the Core model, Common model and Extension schemas.

For an application DBMS, the CIM is mapped into the physical schema of a targeted DBMS (for example, relational). The information stored in the database consists of actual instances of the constructs. Applications can exchange information when they have access to a common DBMS and the mapping occurs in a predictable way.

For application objects, the CIM is used to create a set of application objects in a particular language. Applications can exchange information when they can bind to the application objects.

For exchange parameters, the CIM—expressed in some agreed-to syntax—is a neutral form used to exchange management information by way of a standard set of object APIs. The exchange can be accomplished via a direct set of API calls, or it can be accomplished by exchange-oriented APIs which can create the appropriate object in the local implementation technology.

 

1. CIM Implementation Conformance

2. Meta Schema

The Meta Schema is a formal definition of the model. It defines the terms used to express the model and its usage and semantics (see Appendix B).

The Unified Modeling Language (UML) is used to define the structure of the meta schema. In the discussion that follows, italicized words refer to objects in the figure. The reader is expected to be familiar with UML notation (see http://www.rational.com/uml) and with basic object-oriented concepts in the form of classes, properties, methods, operations, inheritance, associations, objects, cardinality and polymorphism.

1. Definition of the Meta Schema

1. Property Data Types

Property data types are limited to the intrinsic data types, or arrays of such. Structured types are constructed by designing new classes. If the Property is an array property, the corresponding variant type is simply the array equivalent (fixed or variable length) of the variant for the underlying intrinsic type.

This table contains the intrinsic data types and their interpretation:

INTRINSIC DATA TYPE	INTERPRETATION
uint8	Unsigned 8-bit integer
sint8	Signed 8-bit integer
uint16	Unsigned 16-bit integer
sint16	Signed 16-bit integer
uint32	Unsigned 32-bit integer
sint32	Signed 32-bit integer
uint64	Unsigned 64-bit integer
sint64	Signed 64-bit integer
string	UCS-2 string
boolean	Boolean
real32	IEEE 4-byte floating-point
real64	IEEE 8-byte floating-point
datetime	A string containing a date-time
<classname> ref	Strongly typed reference
char16	16-bit UCS-2 character

1. Date, Time, and Interval Types

1. Indicating Additional Type Semantics with Qualifiers

1. Supported Schema Modifications

1. Schema Versions

1. Class Names

1. Qualifiers

Qualifiers are values that provide additional information about classes, associations, indications, methods, method parameters, triggers, instances, properties or references. All qualifiers have a name, type, value, scope, flavor and default value. Qualifiers cannot be duplicated; there cannot be more than one qualifier of the same name for any given class, instance, or property.

The following sections describe meta, standard, optional and user-defined qualifiers. When any of these qualifiers are used in a model, they must be declared in the MOF file before being used. These declarations must abide by the details (name, applied to, type) specified in the tables below. It is not valid to change any of this information for the meta, standard and optional qualifiers. It is possible to change the default values. A default value is the assumed value for a qualifier when it is not explicitly specified for particular model elements.

1. Meta Qualifiers

This table lists the qualifiers that are used to refine the definition of the meta constructs in the model. These qualifiers are used to refine the actual usage of an object class or property declaration within the MOF syntax. These qualifiers are all mutually exclusive.

QUALIFIER	DEFAULT	TYPE	MEANING
ASSOCIATION	FALSE	BOOLEAN	The object class is defining an association.
INDICATION	FALSE	BOOLEAN	The object class is defining an indication.

2. Standard Qualifiers

This table is a list of standard qualifiers that all CIM-compliant implementations are required to handle. Any given object will not have all of the qualifiers listed. It is expected that additional qualifiers will be supplied by extension classes to facilitate the provision of instances of the class and other operations on the class.

It is also important to recognize that not all of these qualifiers can be used together. First, as indicated in the table, not all qualifiers can be applied to all meta-model constructs. These limitations are identified in the "Applies To" column. Second, for a particular meta-model construct like associations, the use of the legal qualifiers may be further constrained because some qualifiers are mutually exclusive or the use of one qualifier implies some restrictions on the value of another qualifier, and so on. These usage rules are documented in the "Meaning" column of the table. Third, legal qualifiers are not inherited by meta-model constructs. For example, the MAXLEN qualifier that applies to properties is not inherited by references.

The "Applies To" column in the table identifies the meta-model construct(s) that can use a particular qualifier. For qualifiers like ASSOCIATION (discussed in the previous section), there is an implied usage rule that the meta qualifier must also be present. For example, the implicit usage rule for the AGGREGATION qualifiers is that the ASSOCIATION qualifier must also be present.

QUALIFIER	DEFAULT	APPLIES TO	TYPE	MEANING
ABSTRACT	FALSE	Class, Association, Indication	BOOLEAN	Indicates that the class is abstract and serves only as a base for new classes. It is not possible to create instances of such classes.
AGGREGATE	FALSE	Reference	BOOLEAN	Defines the "parent" component of an Aggregation association.Usage Rule: The Aggregation and Aggregate qualifiers are used together – Aggregation qualifying the association, and Aggregate specifying the "parent" reference.
AGGREGATION	FALSE	Association	BOOLEAN	Indicates that the association is an aggregation.
ALIAS	NULL	Property, Reference, Method	STRING	Establishes an alternate name for a property or method in the schema.
ARRAYTYPE	"Bag"	Property, Parameter	STRING	Indicates the type of the qualified array. Valid values are "Bag", "Indexed" and "Ordered".Usage rule: The ArrayType qualifier should only be applied to properties and method parameters that are arrays (defined using the square bracket syntax specified in Appendix A).
BITMAP	NULL	Property, Method, Parameter	STRING ARRAY	Indicates which bit positions are significant in a bit map. The position of a specific value in the BitMap array defines an index that is used in selecting a string literal from the BitValues array.
BITVALUES	NULL	Property, Method, Parameter	STRING ARRAY	Provides translation between a bit position value and an associated string. See the description for the BitMap qualifier.
COUNTER	FALSE	Property, Method, Parameter	BOOLEAN	Applicable only to unsigned integer types.Represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^n-1, when it wraps around and starts increasing again from zero. N can be 8, 16, 32 or 64 depending on the datatype of the object to which the qualifier is applied.Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content
DESCRIPTION	NULL	Any	STRING	Provides a description of a Named Element.
DISPLAYNAME	NULL	Any	STRING	Defines a name that will be displayed on UI instead of the actual name of the element.
GAUGE	FALSE	Property, Method, Parameter	BOOLEAN	Applicable only to unsigned integer types.Represents a non-negative integer, which may increase or decrease, but shall never exceed a maximum value. The maximum value can not be greater than 2^n - 1. N can be 8, 16, 32 or 64 depending on the datatype of the object to which the qualifier is applied.The value of a Gauge has its maximum value whenever the information being modeled is greater or equal to that maximum value; if the information being modeled subsequently decreases below the maximum value, the Gauge also decreases.
IN	TRUE	Parameter	BOOLEAN	Indicates that the associated parameter is used to pass values to a method.
KEY	FALSE	Property, Reference	BOOLEAN	Indicates that the property is part of the namespace handle (see Section 5.3.1.2 for information about namespace handles). If more than one property has the KEY qualifier, then all such properties collectively form the key (a compound key). Usage Rule: Keys are written once at object instantiation and must not be modified thereafter. It does not make sense to apply a default value to a KEY-qualified property.
MAPPINGSTRINGS	NULL	Class, Property, Association, Indication, Reference	STRING ARRAY	Mapping strings for one or more management data providers or agents. See Section 2.5.5 and 2.5.6 for more details.
MAX	NULL	Reference	INT	Indicates the maximum cardinality of the reference (i.e. the maximum number of values a given reference can have for each set of other reference values in the association). For example, if an association relates A instances to B instances, and there must be at most one A instance for each B instance, then the reference to A should have a Max(1) qualifier.
MAXLEN	NULL	Property, Method, Parameter	INT	Indicates the maximum length, in characters, of a string data item. When overriding the default value, any unsigned integer value (uint32) can be specified. A value of NULL implies unlimited length.
MAXVALUE	NULL	Property, Method, Parameter	INT	Maximum value of this object.
MIN	0	Reference	INT	Indicates the minimum cardinality of the reference (i.e. the minimum number of values a given reference can have for each set of other reference values in the association). For example, if an association relates A instances to B instances, and there must be at least one A instance for each B instance, then the reference to A should have a Min(1) qualifier.
MINVALUE	NULL	Property, Method, Parameter	INT	Minimum value of this object.
MODEL CORRESPONDENCE	NULL	Property	STRING ARRAY	Indicates a correspondence between an object’s property and other properties in the CIM Schema. Object properties are identified using the following syntax: <schema name> "_" <class or association name> "." <property name>
NONLOCAL	NULL	Reference	STRING	Indicates the location of an instance. Its value is <namespacetype>://<namespacehandle> Usage Rule: Cannot be used with the NonLocalType qualifier.
NONLOCALTYPE	NULL	Reference	STRING	Indicates the type of location of an instance. Its value is <namespacetype>  Usage Rule: Cannot be used with the NonLocal qualifier.
NULLVALUE	NULL	Property	STRING	Defines a value the presence of which indicates that the associated property is NULL – that is that the property cannot be considered as having a valid or meaningful value. The conventions and restrictions used for defining null values are the same as those applicable to the ValueMap qualifier. Note this qualifier cannot be overridden as it seems unreasonable to permit a subclass to return a different null value to that of the superclass.
OUT	FALSE	Parameter	BOOLEAN	Indicates that the associated parameter is used to return values from a method.
OVERRIDE	NULL	Property, Method, Reference	STRING	Indicates that the property, method, or reference in the derived class overrides the similar construct (of the same name) in the parent class in the inheritance tree, or in the specified parent class. The value of this qualifier MAY identify the parent class whose subordinate construct (property, method, or reference) is overridden. The format of the string to accomplish this is:[<class>.]<subordinate construct>If the class name is omitted, the Override applies to the subordinate construct in the parent class in the inheritance tree.Usage Rule: The Override qualifier can only refer to constructs based on the same meta model. Also, it is not allowed to change a construct's name or signature when overriding.
PROPAGATED	NULL	Property	STRING	The propagated qualifier is a string-valued qualifier that contains the name of the key that is being propagated. Its use assumes the existence of only one weak qualifier on a reference that has the containing class as its target. The associated property must have the same value as the property named by the qualifier in the class on the other side of the weak association. The format of the string to accomplish this is: [<class>.]<subordinate construct> Usage Rule: When the PROPAGATED qualifier is used, the KEY qualifier must be specified with a value of TRUE.
READ	TRUE	Property	BOOLEAN	Indicates that the property is readable.
REQUIRED	FALSE	Property	BOOLEAN	Indicates that a non-NULL value is required for the property.
REVISION	NULL	Class, Association, Indication, Schema	STRING	Provides the minor revision number of the schema object. Usage Rule: The VERSION qualifier must be present to supply the major version number when the REVISION qualifier is used.
SCHEMA	NULL	Property, Method	STRING	The name of the schema in which the feature is defined.
SOURCE	NULL	Class, Association, Indication, Reference	STRING	Indicates the location of an instance. Its value is <namespacetype>://<namespacehandle> Usage Rule: Cannot be used with the SourceType  qualifier.
SOURCETYPE	NULL	Class, Association, Indication, Reference	STRING	Indicates the type of location of an instance. Its value is <namespacetype>  Usage Rule: Cannot be used with the Source qualifier.
STATIC	FALSE	Property, Method	BOOLEAN	For methods indicates that the method is a class method that does not depend on any per-instance data.For properties, indicates that the property is a class variable rather than an instance variable.
TERMINAL	FALSE	Class	BOOLEAN	Indicate that the class can have no subclasses. If such a subclass is declared the compiler will generate an error. Note this qualifier cannot coexist with the Abstract qualifier. If both are specified the compiler generates an error.
UNITS	NULL	Property, Method, Parameter	STRING	Provides units in which the associated data item is expressed. For example, a Size data item might have Units ("bytes"). The complete set of standard units is defined in Appendix C.
VALUEMAP	NULL	Property, Method, Parameter	STRING ARRAY	Defines the set of permissible values for this property, method return type or method parameter. The ValueMap can be used alone, or in combination with the Values qualifier. When used in combination with the Values qualifier, the location of the value in the ValueMap array provides the location of the corresponding entry in the Values array.ValueMap may only be used with string and integer values. The syntax for representing an integer value in the ValueMap array is:[+|-]digit[*digit]The content, maximum number of digits and represented value are constrained by the type of the associated property. For example, uint8 may not be signed, must be less than four digits, and must represent a value less than 256.
VALUES	NULL	Property, Method, Parameter	STRING ARRAY	Provides translation between an integer value and an associated string. If a ValueMap qualifier is not present, the Values array is indexed (zero relative) using the value in the associated property, method return type or method parameter. If a ValueMap qualifier is present, the Values index is defined by the location of the property value in the ValueMap.
VERSION	NULL	Class, Schema, Association, Indication	STRING	Provides the major version number of the schema object. This is incremented when changes are made to the schema that alter the interface.
WEAK	FALSE	Reference	BOOLEAN	Indicates that the keys of the referenced class include the keys of the other participants in the association. This qualifier is used when the identity of the referenced class depends on the identity of the other participants in the association. No more than one reference to any given class can be weak. The other classes in the association must define a key. The keys of the other classes in the association are repeated in the referenced class and tagged with a propagated qualifier.
WRITE	FALSE	Property	BOOLEAN	Indicates whether write access is allowed for a property by any "consumers" of that property's data. This qualifier does not address the initial assignment of a property value, nor its maintenance by its "provider". It describes the maximal level of access that is allowed, and does not address whether security and authorization restrictions may actually prevent writing of the data. A value of true indicates that the property is readable and writable by "consumers", given appropriate administrative authorization. A value of false indicates that the property is only readable by "consumers", regardless of authorization.

3. Optional Qualifiers

The optional qualifiers listed in this table address situations that are not common to all CIM-compliant implementations. Thus, CIM-compliant implementations can ignore optional qualifiers since they are not required to interpret or understand these qualifiers. These are provided in the specification to avoid random user-defined qualifiers for these recurring situations.

Qualifer	Default	Applies To	Type	Meaning
DELETE	FALSE	Association, Reference	BOOLEAN	For associations: Indicates that the qualified association must be deleted if any of the objects referenced in the association are deleted, AND the respective object referenced in the association is qualified with IFDELETED. For references: Indicates that the referenced object must be deleted if the association containing the reference is deleted, AND qualified with IFDELETED, or if any of the objects referenced in the association are deleted AND the respective object referenced in the association is qualified with IFDELETED. Usage Rule: Applications must to chase associations according to the modeled semantic and delete objects appropriately. Note: This usage rule must be verified when the CIM security model is defined.
EXPENSIVE	FALSE	Property, Reference, Class, Association, Method	BOOLEAN	Indicates the property or class is expensive to compute.
IFDELETED	FALSE	Association, Reference	BOOLEAN	Indicates that all objects qualified by DELETE within the association must be deleted if the referenced object or the association, respectively, is deleted.
INVISIBLE	FALSE	Association, Property, Method, Reference, Class	BOOLEAN	Indicates that the association is defined only for internal purposes (for example, for definition of dependency semantics) and should not be displayed (for example, in maps).
LARGE	FALSE	Property, Class	BOOLEAN	Indicates the property or class requires a large amount of storage space.
PROVIDER	NULL	Any	STRING	An implementation specific handle to the instrumentation that populates those elements in the schemas which refer to dynamic data.
SYNTAX	NULL	Property, Reference, Method, Parameter	STRING	Specific type assigned to a data item. Usage Rule: Must be used with the SyntaxType qualifier.
SYNTAXTYPE	NULL	Property, Reference, Method, Parameter	STRING	Defines the format of the SYNTAX qualifier. Usage Rule: Must be used with the SYNTAX qualifier.
TRIGGERTYPE	NULL	Class, Property, Method, Association, Indication, Reference	STRING	Indicates the circumstances under which a trigger is fired. Usage Rule: The trigger types vary by meta-model construct. For classes and associations, the legal values are CREATE, DELETE, UPDATE and ACCESS. For properties and references, the legal values are: UPDATE and ACCESS. For methods, the legal values are BEFORE and AFTER. For indications, the legal values are THROWN.
UNKNOWN VALUES	NULL	Property	STRING ARRAY	Defines a set of values the presence of which indicates that the value of the associated property is unknown – that is that the property cannot be considered as having a valid or meaningful value. The conventions and restrictions used for defining unknown values are the same as those applicable to the ValueMap qualifier. Note this qualifier cannot be overridden as it seems unreasonable to permit a subclass to treat as a known value a value that is treated as unknown by some superclass.
UNSUPPORTEDVALUES	NULL	Property	STRING ARRAY	Defines a set of values the presence of which indicates that the value of the associated property is unsupported – that is that the property cannot be considered as having a valid or meaningful value. The conventions and restrictions used for defining unsupported values are the same as those applicable to the ValueMap qualifier. Note this qualifier cannot be overridden as it seems unreasonable to permit a subclass to treat as a supported value a value that is treated as unknown by some superclass.

4. User-defined Qualifiers

The user can define any additional arbitrary named qualifiers. However, it is recommended that only defined qualifiers be used, and that the list of qualifiers be extended only if there is no other way to accomplish a particular objective.

5. Mapping MIF Attributes

Mapping Management Information Format (MIF) attributes to CIM Properties can be accomplished using the MAPPINGSTRINGS qualifier. This qualifier provides a mechanism to specify the mapping from DMTF and vendor-defined MIF groups to specific properties. This allows for mapping using either Domain or Recast Mapping.

Every MIF group contains a unique identification that is defined using the class string, which is defined as follows:

defining body|specific name|version

where defining body is the creator and owner of the group, specific name is the unique name of the group and version is a three-digit number that identifies the version of the group definition. In addition, each attribute has a unique numeric identifier, starting with the number one.

Therefore, the mapping qualifier can be represented as a string that is formatted as follows:

MIF.defining body|specific name|version.attributeid

where MIF is a constant defining this as a MIF mapping followed by a dot. This is then followed by the class string for the group this defines, and optionally followed by a dot and the identifier of a unique attribute.

In the case of a Domain Mapping, all of the above information is required, and provides a way to map an individual MIF attribute to a particular CIM Property. In the case of the recast mapping, a CIM class can be recast from a MIF group and only the MIF constant, followed by the dot separator followed by the class string, is required.

For example, a Domain Mapping of a DMTF MIF attribute to a CIM property would be as follows:

[MAPPINGSTRINGS{"MIF.DMTF|ComponentID|001.4"},READ]
SerialNumber = "";

The above declaration defines a mapping to the SerialNumber property from the DMTF Standard Component ID group's serial number attribute. Because the qualifiers of CIM are a superset of those found in MIF syntax, any qualifier may be overridden in the CIM definition.

To recast an entire MIF group into a CIM Object, the mapping string can be used to define an entire Class. For example:

[MAPPINGSTRINGS {"MIF.DMTF|Software Signature|002"}]
class MicroSoftWord : SoftwareSignature
{
...
}

6. Mapping Generic Data to CIM Properties

2. Managed Object Format

The management information is described in a language based on Interface Definition Language (IDL) [3] called the Managed Object Format (MOF). This document uses the term MOF specification to refer to a collection of management information described in a manner conformant to the MOF syntax.

Elements of MOF syntax are introduced on a case-by-case basis with examples. In addition, a complete description of the MOF syntax is provided in Appendix A.

Note: All grammars defined in this specification use the notation defined in [7]; any exceptions are stated with the grammar.

The MOF syntax is a way to describe object definitions in textual form. It establishes the syntax for writing definitions. The main components of a MOF specification are textual descriptions of classes, associations, properties, references, methods and instance declarations and their associated qualifiers. Comments are permitted.

In addition to serving the need for specifying the managed objects, a MOF specification can be processed using a compiler. To assist the process of compilation, a MOF specification consists of a series of compiler directives.

A MOF file can be encoded in either Unicode or UTF-8.

1. MOF usage

The managed object descriptions in a MOF specification can be validated against an active namespace (See Section 5). Such validation is typically implemented in an entity acting in the role of a Server. This section describes the behavior of an implementation when introducing a MOF specification into a namespace. Typically, such a process validates both the syntactic correctness of a MOF specification, as well as the semantic correctness of such a specification against a particular Implementation. A MOF specification can be validated for the syntactic correctness alone, in a component such as a MOF compiler.

2. Class Declarations

A class declaration is treated as an instruction to create a new class. It is a local matter as to whether the process of introducing a MOF specification into a namespace is allowed to add classes or modify classes.

Any class referenced in the specification of a class or reference specification must exist at the time of the specification (that is, forward references are not allowed).

3. Instance Declarations

Classes must be defined before they are used to declare instances. However, if a class definition is already resident within the namespace, that class declaration need not appear in a MOF specification that introduces the instances of that class.

Any instance declaration is treated as an instruction to create a new instance where the object's key values do not already exist, or an instruction to modify an existing instance where an object with identical key values already exists.

4. MOF Components
1. Keywords

All keywords in the MOF syntax are case-insensitive.

2. Comments

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 carriage return, line feed 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 meta model and as such, will not be preserved across compilations. In other words, the output of a MOF compilation is not required to include any comments.

3. 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.

4. 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 Section 1. 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 must 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 Appendix F, Unicode Usage.

5. 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.

1. Declaring a Class

1. Subclasses

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.

2. 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 any such property is automatically assigned its default value unless the instance declaration explicitly assigns a value to the property.

3. Class and Property Qualifiers

Qualifiers are meta data 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 meta schema). 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 { "this", "a", "bag", "is" } // string []

id(12) // uint32

idlist { 21, 22, 40, 43 } // uint32 []

apple(3.14) // real32

oranges { -1.23E+02, 2.1 } // real32 []

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

For example:

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

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

Qualifiers can be transmitted automatically from classes to derived classes, or from classes to instances, subject to certain rules. The rules behind how the transmission 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 transmitted to all of its derived classes, or it may be designated as belonging specifically to that class and not transmittable. In addition, the qualifier flavor can be used to control whether or not derived classes can 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. 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.

The recognized flavor types are:

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 : label_ll_cc 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. Example: if an English description is translated into Mexican Spanish the actual name of the qualifier is: DESCRIPTION_es_MX.	no

4. Key Properties

1. Association Declarations

An association is a special kind of a class describing a link between other classes. As such, they also provide a type system for instance constructions. Associations are just like other classes with a few additional semantics explained below.

1. Declaring an Association

1. Subassociations

To indicate that an association is a subassociation of another association, the same notation as for ordinary classes is used, i.e. the derived association is declared by using a colon followed by the superassociation name. (An example is provided above.)

2. Key References and Properties

Instances of an association also require some mechanism through which the instances can be distinguished, implied by the fact that they are just a special kind of a class. Designating one ore more references/properties with the reserved KEY qualifier provides instance identification.

A reference/property of an association is (part of) the association key if the KEY qualifier is applied.

    [Association, Aggregation]
class CIM_Component
{
        [Aggregate, Key]
    CIM_ManagedSystemElement Ref GroupComponent;
        [Key]
    CIM_ManagedSystemElement Ref PartComponent;
};

In principle, the key definition of association follows the same rules as for ordinary classes. Compound keys are supported in the same way. Also a new subassociation cannot define any additional key properties/references.

If any reference to a class has the WEAK qualifier, the KEY-qualified properties of the other class, whose reference is not WEAK-qualified are propagated to the class. (see subchapter 4.5.5 "Key Properties").

3. Object References

1. 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 meta qualifiers are declared as:

Qualifier Association : boolean = false,

Scope(class, association), Flavor(DisableOverride);

Qualifier Indication : boolean = false,

Scope( class, indication), Flavor(DisableOverride);


See Appendix B for the complete list of standard qualifiers.

2. Instance Declarations