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

1. Instance Aliasing

An alias can be assigned to an instance using this 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 Section4.12.2 Initializing References using Aliases.

2. Arrays

1. 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 Section 2.2. 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 this 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 this example, a Configure method is defined on the Physical DiskDrive class. It takes a DiskPartitionConfiguration object reference 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);
};

2. 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:

compiler Directive	Interpretation
#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 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.
#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 namespace( )	This pragma is used to specify a Namespace path. The syntax needs to conform to the following: <namespacetype>://<namespacehandle>
#pragma nonlocal()	See the description of the NonLocal qualifier for an explanation of this pragma.Usage Rule: Cannot be used with NonLocalType pragma.
#pragma nonlocaltype()	See the description of the NonLocalType qualifier for an explanation of this pragma. Usage Rule: Cannot be used with NonLocal pragma
#pragma source()	See the description of the Source qualifier for an explanation of this pragma. Usage Rule: Cannot be used with sourcetype pragma
#pragma sourcetype()	See the description of the SourceType qualifier for an explanation of this pragma.Usage Rule: Cannot be used with source pragma.

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.

3. 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 is found in Appendix A, MOF Syntax Grammar Description.

1. 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 such as \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 [10], 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.

2. Character Constants

Character and wide-character constants are specified as.

'a'

'\n'

'1'

'\x32'

Note: Forms such as octal escape sequences (e.g. ‘\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.

3. Integral Constants

Integer constants may be decimal, binary, octal or hexadecimal.

For example, these 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.

4. Floating-Point Constants

Floating point constants are declared as specified by IEEE in Ref. [6].

For example, these 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.

5. 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=\"acme\",LogicalDisk.Drive=\"C\""

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

An object reference can also be an alias. See Section 4.12.2 for more details.

6. NULL

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

4. Initializers

Initializers are used both in class declarations for default values and instance declarations to initialize a property to a value. The format of initializer values is specified in Section 2 and its subsections.

The initializer value must match the property data type. The only exceptions are the NULL value, which may be used for any data type, and integral values, used for characters.

1. 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 of array elements is delimited with curly brackets.

For example, given this 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

};

this is a valid instance declaration:

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 Section 4.8.2 for additional information on declaring arrays, and the distinctions between bags, ordered arrays and indexed arrays.

2. Initializing References Using Aliases

2. Naming

1. Background

1. Management Tool Responsibility for an Export Operation

The management tool must be able to create unique key values for each distinct object it places in the MOF file.

For each instance placed in the MOF file, the management tool must maintain a mapping from the MOF file keys to the native key mechanism.

2. Management Tool Responsibility for an Import Operation

1. Weak Associations: Supporting Key Propagation

CIM provides a mechanism to name instances within the context of other object instances. For example, if a management tool is handling a local system, then it can refer to the C drive or the D drive. However, if a management tool is handling multiple machines, it must refer to the C drive on machine X and the C drive on machine Y. In other words, the name of the drive must include the name of the hosting machine. CIM supports the notion of weak associations to specify this type of key propagation.

A weak association is defined using a qualifier. For example:

Qualifier Weak: boolean = false, Scope(reference), Flavor(DisableOverride);

The key(s) of the referenced class includes the key(s) of the other participants in the WEAK association. This situation occurs when the referenced class identity depends on the identity of other participants in the association.

Usage Rule: This qualifier can only be specified on one of the references defined for an association. The Weak referenced object is the one that depends on the other object for identity.

This figure shows an example. There are three classes: ComputerSystem, OperatingSystem and Local User. The Operating System class is weak with respect to the Computer System class, since the runs association is marked weak. Similarly, the Local User class is weak with respect to the Operating System class, since the association is marked weak.



Figure -1 Example of Weak Association

In the context of a weak association definition, the Computer System class is a scoping class for the Operating System class, since its keys are propagated to the Operating System class. The Computer System and the Operating System classes are both scoping classes for the Local User class, since the Local User class gets keys from both. Finally, the Computer System is referred to as a Top Level Object (TLO) because it is not weak with respect to any other class. The fact that a particular class is a top-level object is inferred because no references to that class are marked with the WEAK qualifier. In addition, Top Level Objects must have the possibility of an enterprise-wide, unique key. An example may be a computer’s IP address in a company’s enterprise-wide IP network. The goal of the TLO concept is to achieve uniqueness of keys in the model path portion of the object name. In order to come as close as possible to this goal, TLO must have relevance in an enterprise context.

Objects in the scope of another object can in turn be a scope for other objects; hence, all model object instances are arranged in directed graphs with the Top Level Object’s (TLO’s) as peer roots. The structure of this graph – in other words, which classes are in the scope of another given class – is defined as part of CIM by means of associations qualified with the WEAK qualifier.

1. Referencing Weak Objects

A reference to an instance of an association includes the propagated keys. The properties must have the propagated qualifier that identifies which class the property originates in and what the name of the property is in that class – for example

instance of Acme_has
{
anOS = "Acme_OS.Name=\"acmeunit\",SystemName=\"UnixHost\"";
aUser = "Acme_User.uid=33,OSName=\"acmeunit\",SystemName=\"UnixHost\"";
};

 

The operating system being weak to system would be declared as:

Class Acme_OS
{
[key]
String Name;
[key, Propagated("CIM_System.Name")]
String SystemName;
};

The user class being weak to operating system would be declared as:

Class Acme_User
{
[key]
String uid;
[key, Propagated("Acme_OS.Name")]
String OSName;
[key, Propagated("Acme_OS.SystemName")]
String SystemName;
};

2. Naming CIM Objects

Since CIM allows for multiple implementations, it is not sufficient to think of the name of an object as just the combination of properties that have the KEY qualifier. The name must also identify the implementation that actually hosts the objects. The object name consists of the Namespace Path, which provides access to a CIM implementation, plus the Model Path, which provides full navigation within the CIM schema. The namespace path is used to locate a particular name space. The details of the namespace path are dependent on a particular implementation. The model path is the concatenation of the properties of a class that are qualified with the KEY qualifier. When the class is weak with respect to another class, the model path includes all key properties from the scoping objects. The following figure shows the various components of an object name. These are described in more details in the following sections.



Figure -1 Object Naming

1. Namespace Path

A Namespace path references a namespace within an implementation that is capable of hosting CIM objects.

A Namespace path resolves to a namespace hosted by a CIM-Capable implementation (in other words, a CIM Object Manager). Unlike the Model Path, the details of the Namespace path are implementation-specific. Therefore, the Namespace path provides two pieces of information: it identifies the type of implementation or namespace type, and it provides a handle that references a particular implementation or namespace handle.

1. Namespace Type

The namespace type classifies or identifies the type of implementation. The provider of such an implementation is responsible for describing the access protocol for that implementation. This is analogous to specifying http or ftp in a browser.

Fundamentally, a namespace type implies an access protocol or API set that can be used to manipulate objects. These APIs would typically support: (1) generating a MOF file for a particular scope of classes and associations, (2) importing a MOF file and (3) manipulating instances. A particular management platform may have a variety of ways to access management information. Each of these ways must have a namespace type definition. Given this type, there would be an assumed set of mechanisms for exporting, importing and updating instances.

2. Namespace Handle

1. Model Path

The object name constructed as a scoping path through the CIM schema is referred to as a Model Path.A model path is a combination of the key properties values qualified by the class name. It is solely described by CIM elements and is absolutely implementation-independent. It is used to describe the path to a particular object or to identify a particular object within a namespace. The name of any object is a concatenation of named key property values, including all key values of its scoping objects.. When the class is weak with respect to another class, the model path includes all key properties from the scoping objects. 

The syntax of Model Path is:

<Qualifyingclass>.<key1>=<value1>[,<keyx>=<valuex>]*

2. Specifying the Object Name

1. Specifying Object Names in MOF Files

The object name can be used as the value for object references and for object queries.

1. Synchronizing Namespaces

When a MOF is loaded into a system that is able to access and manipulate the source implementation, a higher level of integration is possible between two CIM-based implementations. In particular, the receiving implementation can synchronize changes with the sending implementation. This situation is shown in this figure and requires a way to record information about the namespace path of the source in the MOF. The arrow labeled "Dynamic Access to Loaded Information" implies that Mgmt_ABC has the capability to access information about an instance of Mgmt_X because it understands Mgmt_X's access protocol. All it must know is the handle (namespace path) for the source.

The following figure is a sample MOF file for the situation illustrated in the previous figure. Notice the various uses of the SOURCE pragma and the SOURCE qualifier.



Figure -1 Namespace Path

The namespace path can be provided in one of two ways: 1) a qualifier on each object and association or 2) a pragma. The value for the pragma and the qualifier is exactly the same:

Source(<namespacetype>:\\<namespace_handle>)

When the information is provided as a pragma, it is assumed to be the same for all instances in the MOF file. This pragma is shown in this figure for the circle and triangle example:

#pragma source("Mgmt_X://EastCoast") class Figs_Circle { [key] uint32 Name; string Color; }; class Figs_Triangle { [key] uint32 Label; string Color; uint32 Area; }; [Association] class Figs_CircleToTriangle { Figs_Circle REF ACircle; Figs_Triangle REF ATriangle; }; [Association] class Figs_Covers { Figs_Triangle REF Over; Figs_Triangle REF Under; };

instance of Figs_Triangle {Label=2;Color="Blue";Area=12}; instance of Figs_Triangle {Label=4;Color="Blue";Area=12}; instance of Figs_Circle {Name=1;Color="Blue"}; instance of Figs_Circle {Name=3;Color="Blue"}; instance of Figs_Circle {Name=5;Color="Blue"}; instance of Figs_CircleToTriangle { ACircle="Figs_Circle.Name=1"; ATriangle="Figs_Triangle.Label=2"; }; instance of Figs_CircleToTriangle { ACircle="Figs_Circle.Name=5"; ATriangle="Figs_Triangle.Label=2"; }; [SourceType("Mgmt_X") ] instance of Figs_CircleToTriangle { ACircle="EastCoast:Figs_Circle.Name=5"; ATriangle="EastCoast:Figs_Triangle.Label=4"; }; instance of Figs_Covers { [SourceType("Mgmt_X") ] Over="EastCoast:Figs_Triangle.Label=2"; Under="Figs_Triangle.Label=4"; };

Figure -2 Pragma Example

The import operation must preserve namespace path information so if either this platform or another platform understands how to manipulate an implementation of type <namespacetype> and has access to the <namespace_handle>, it can manipulate one or more of the instances in the source.

The namespace path can also be specified using the instance-based Source qualifier. This qualifier marks a particular object or an association. This is illustrated in Figure 5-3. Note: When a pragma is specified and a qualifier is specified, the qualifier overrides the pragma.

Class Figs_Circle { [key] uint32 Name; string Color; }; class Figs_Triangle { [key] uint32 Label; string Color; uint32 Area; }; [Association] class Figs_CircleToTriangle { Figs_Circle REF ACircle; Figs_Triangle REF ATriangle; }; [Association] class Figs_Covers { Figs_Triangle REF Over; Figs_Triangle REF Under; };

[source("Mgmt_X://EastCoast")] instance of Figs_Triangle {Label=2;Color="Blue";Area=12}; [source("Mgmt_X://EastCoast")] instance of Figs_Triangle {Label=4;Color="Blue";Area=12}; [source("Mgmt_X://EastCoast")] instance of Figs_Circle {Name=1;Color="Blue"}; [source("Mgmt_X://EastCoast")] instance of Figs_Circle {Name=3;Color="Blue"}; [source("Mgmt_X://EastCoast")] instance of Figs_Circle {Name=5;Color="Blue"}; [source("Mgmt_X://EastCoast")] instance of Figs_CircleToTriangle { ACircle="Figs_Circle.Name=1"; ATriangle="Figs_Triangle.Label=2"; }; [source("Mgmt_X://EastCoast")] instance of Figs_CircleToTriangle { ACircle="Figs_Circle.Name=5"; ATriangle="Figs_Triangle.Label=2"; }; [source("Mgmt_X://EastCoast")] instance of Figs_CircleToTriangle { ACircle="Figs_Circle.Name=5"; ATriangle="Figs_Triangle.Label=4"; }; [source("Mgmt_X://EastCoast")] instance of Figs_Covers { [nonlocal("Mgmt_X://EastCoast")] Over="Figs_Triangle.Label=2"; Under="Figs_Triangle.Label=4"; };

Figure -3 Namespace Path Example

2. Building References Between Management Systems

2. Mapping Existing Models Into CIM

Existing models have their own meta model and model. There are three types of mapping that can occur between meta schemas: technique, recast and domain. Each of these mappings can be applied when converting from MIF syntax to MOF syntax.

1. Technique Mapping

A technique mapping provides a mapping that uses the CIM meta-model constructs to describe the source modeling technique’s meta constructs (for example, MIF, GDMO and SMI). Essentially, the CIM meta model is a meta meta-model for the source technique.



Figure -1 Technique Mapping Example

The DMTF uses the management information format (MIF) as the meta model to describe distributed management information in a common way. Therefore, it is meaningful to describe a technique mapping in which the CIM meta model is used to describe the MIF syntax.

The mapping presented here takes the important types that can appear in a MIF file and then creates classes for them. Thus, component, group, attribute, table and enum are expressed in the CIM meta model as classes. In addition, associations are defined to document how these are combined. Figure 6-2 illustrates the results:



Figure -2 MIF Technique Mapping Example

2. Recast Mapping

A recast mapping provides a mapping of the sources’ meta constructs into the targeted meta constructs, so that a model expressed in the source can be translated into the target. The major design work is to develop a mapping between the sources’ meta model and the CIM meta model. Once this is done, the source expressions are recast.



Figure -1 Recast mapping

This is an example of a recast mapping for MIF, assuming:

DMI attributes -> CIM properties

DMI key attributes -> CIM key properties

DMI groups -> CIM classes

DMI components -> CIM classes

The standard DMI ComponentID group might be recast into a corresponding CIM class:

Start Group
Name = "ComponentID"
Class = "DMTF|ComponentID|001"
ID = 1
Description = "This group defines the attributes common to all "
"components. This group is required."
Start Attribute
Name = "Manufacturer"
ID = 1
Description = "Manufacturer of this system."
Access = Read-Only
Storage = Common
Type = DisplayString(64)
Value = ""
End Attribute
Start Attribute
Name = "Product"
ID = 2
Description = "Product name for this system."
Access = Read-Only
Storage = Common
Type = DisplayString(64)
Value = ""
End Attribute
Start Attribute
Name = "Version"
ID = 3
Description = "Version number of this system."
Access = Read-Only
Storage = Specific
Type = DisplayString(64)
Value = ""
End Attribute
Start Attribute
Name = "Serial Number"
ID = 4
Description = "Serial number for this system."
Access = Read-Only
Storage = Specific
Type = DisplayString(64)
Value = ""
End Attribute
Start Attribute
Name = "Installation"
ID = 5
Description = "Component installation time and date."
Access = Read-Only
Storage = Specific
Type = Date
Value = ""
End Attribute
Start Attribute
Name = "Verify"
ID = 6
Description = "A code that provides a level of verification that the "
"component is still installed and working."
Access = Read-Only
Storage = Common
Type = Start ENUM
0 = "An error occurred; check status code."
1 = "This component does not exist."
2 = "Verification is not supported."
3 = "Reserved."
4 = "This component exists, but the functionality is untested."
5 = "This component exists, but the functionality is unknown."
6 = "This component exists, and is not functioning correctly."
7 = "This component exists, and is functioning correctly."
End ENUM
Value = 1
End Attribute
End Group

A corresponding CIM class might be the following. Note that properties in the example include an ID qualifier to represent the corresponding DMI attribute’s ID. Here, a user-defined qualifier may be necessary.

[Name ("ComponentID"), ID (1), Description (
"This group defines the attributes common to all components. "

"This group is required.")]


class DMTF|ComponentID|001 {

[ID (1), Description ("Manufacturer of this system."), maxlen (64)]
string Manufacturer;
[ID (2), Description ("Product name for this system."), maxlen (64)]
string Product;
[ID (3), Description ("Version number of this system."), maxlen (64)]
string Version;
[ID (4), Description ("Serial number for this system."), maxlen (64)]
string Serial_Number;
[ID (5), Description("Component installation time and date.")]
datetime Installation;
[ID (6), Description("A code that provides a level of verification "
"that the component is still installed and working."),

Value (1)]
string Verify;
};

3. Domain Mapping

A domain mapping takes a source expressed in a particular technique and maps its content into either the core or common models, or extension sub-schemas of the CIM. This mapping does not rely heavily on a meta-to-meta mapping; it is primarily a content-to-content mapping. In one case, the mapping is actually a re-expression of content in a more common way using a more expressive technique.

This is an example of how CIM properties can be supplied by DMI, using information from the DMI disks group ("DMTF|Disks|002"). For a hypothetical CIM disk class, the CIM properties are expressed as:

CIM "Disk" property	Can be sourced from DMI group/attribute
StorageType StorageInterface RemovableDrive RemovableMedia DiskSize	"MIF.DMTF|Disks|002.1" "MIF.DMTF|Disks|002.3" "MIF.DMTF|Disks|002.6" "MIF.DMTF|Disks|002.7" "MIF.DMTF|Disks|002.16"

 

4. Mapping Scratch Pads

In general, when the content of models are mapped between different meta schemas, information gets lost or is missing. To fill this gap, "scratch pads" are expressed in the CIM meta model using qualifiers, which are actually extensions to the meta model (for example, see section 2.5.5 Mapping MIF Attributes and section 2.5.6 Mapping Generic Data to CIM Properties). These scratch pads are critical to the exchange of core, common and extension model content with the various technologies used to build management applications.

4. Repository Perspective

1. DMTF MIF Mapping Strategies

1. Recording Mapping Decisions

1. MOF Syntax Grammar Description

1. CIM META SCHEMA

// version 2.2

Qualifier Abstract : boolean = false, Scope(class, association, indication),
Flavor(disableoverride, restricted);

Qualifier Aggregate : boolean = false, Scope(reference),
Flavor(disableoverride, tosubclass);

Qualifier Aggregation : boolean = false, Scope(association),
Flavor(disableoverride, tosubclass);

Qualifier Alias : string = null, Scope(property, reference, method),
Flavor(translatable);

Qualifier ArrayType : string = "Bag", Scope(property, parameter);

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

Qualifier BitMap : string[], Scope(property, method, parameter);

Qualifier BitValues : string[], Scope(property, method, parameter),
Flavor(Translatable);

Qualifier Counter : boolean = false, Scope(property, method, parameter);

Qualifier Delete : boolean = false, Scope(association, reference);

Qualifier Description : string = null, Scope(any), Flavor(translatable);

Qualifier DisplayName : string = null, Scope(any), Flavor(translatable);

Qualifier Expensive : boolean = false,
Scope(property, reference, method, class, association);

Qualifier Gauge : boolean = false, Scope(property, method, parameter);

Qualifier Ifdeleted : boolean = false, Scope(association, reference);

Qualifier In : boolean = true, Scope(parameter), Flavor(disableoverride);

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

Qualifier Invisible : boolean = false,
Scope(reference, association, class,property, method);

Qualifier Key : boolean = false, Scope(property, reference),
Flavor(disableoverride);

Qualifier Large : boolean = false, Scope(property, class);

Qualifier MappingStrings : string[],
Scope(class, property, association, indication, reference);

Qualifier Max : uint32 = null, Scope(reference);

Qualifier MaxLen : uint32 = null, Scope(property, method, parameter);

Qualifier MaxValue : sint64 = null, Scope(property, method, parameter);

Qualifier Min : uint32 = 0, Scope(reference);

Qualifier MinValue : sint64 = null, Scope(property, method, parameter);

Qualifier ModelCorrespondence : string[], Scope(property);

Qualifier NonLocal : string = null, Scope(reference);

Qualifier NonLocalType : string = null, Scope(reference);

Qualifier NullValue : string = null, Scope(property),
Flavor(tosubclass, disableoverride);

Qualifier Out : boolean = false, Scope(parameter), Flavor(disableoverride);

Qualifier Override : string = null, Scope(property, method, reference),
Flavor(disableoverride);

Qualifier Propagated : string = null, Scope(property, reference),
Flavor(disableoverride);

Qualifier Provider : string = null, Scope(any);

Qualifier Read : boolean = true, Scope(property);

Qualifier Required : boolean = false, Scope(property);

Qualifier Revision : string = null, Scope(schema, class, association, indication),
Flavor(translatable);

Qualifier Schema : string = null, Scope(property, method),
Flavor(disableoverride, translatable);

Qualifier Source : string = null, Scope(class, association, indication);

Qualifier SourceType : string = null,
Scope(class, association, indication,reference);

Qualifier Static : boolean = false, Scope(property, method), Flavor(disableoverride);

Qualifier Syntax : string = null, Scope(property, reference, method, parameter);

Qualifier SyntaxType : string = null, Scope(property, reference, method, parameter);

Qualifier Terminal : boolean = false, Scope(class);

Qualifier TriggerType : string = null,
Scope(class, property, reference, method, association, indication);

Qualifier Units : string = null, Scope(property, method, parameter),
Flavor(translatable);

Qualifier UnknownValues : string[], Scope(property),
Flavor(disableoverride, tosubclass);

Qualifier UnsupportedValues : string[], Scope(property),
Flavor(disableoverride, tosubclass);

Qualifier ValueMap : string[], Scope(property, method, parameter);

Qualifier Values : string[], Scope(property, method, parameter),
Flavor(translatable);

Qualifier Version : string = null,
Scope(schema, class, association, indication),
Flavor(translatable);Qualifier Weak : boolean = false, Scope(reference),
Flavor(disableoverride, tosubclass);

Qualifier Write : boolean = false, Scope(property);

// ==================================================================
// NamedElement
// ==================================================================
[Version( "2" ), Revision( "2" ), Description(
"The Meta_NamedElement class represents the root class for the "
"Metaschema. It has one property: Name, which is inherited by all the "
"non-association classes in the Metaschema. Every metaconstruct is "
"expressed as a descendent of the class Meta_Named Element.") ]
class Meta_NamedElement
{
[Description (
"The Name property indicates the name of the current Metaschema element. "
"The following rules apply to the Name property, depending on the "
"creation type of the object:<UL><LI>Fully-qualified class names, such "
"as those prefixed by the schema name, are unique within the schema."
"<LI>Fully-qualified association and indication names are unique within "
"the schema (implied by the fact that association and indication classes "
"are subtypes of Meta_Class).<LI>Implicitly-defined qualifier names are "
"unique within the scope of the characterized object; that is, a named "
"element may not have two characteristics with the same name."
"<LI>Explicitly-defined qualifier names are unique within the defining "
"schema. An implicitly-defined qualifier must agree in type, scope and "
"flavor with any explicitly-defined qualifier of the same name."
"<LI>Trigger names must be unique within the property, class or method "
"to which the trigger applies.<LI>Method and property names must be "
"unique within the domain class. A class can inherit more than one "
"property or method with the same name. Property and method names can be "
"qualified using the name of the declaring class.<LI>Reference names "
"must be unique within the scope of their defining association class. "
"Reference names obey the same rules as property names.</UL><B>Note:</B> "
"Reference names are not required to be unique within the scope of the "
"related class. Within such a scope, the reference provides the name of "
"the class within the context defined by the association.") ]
string Name;
};

// ==================================================================
// QualifierFlavor
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_QualifierFlavor class encapsulates extra semantics attached "
"to a qualifier such as the rules for transmission from superClass "
"to subClass and whether or not the qualifier value may be translated "
"into other languages") ]
class Meta_QualifierFlavor:Meta_NamedElement
{
};

// ==================================================================
// Schema
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Schema class represents a group of classes with a single owner."
" Schemas are used for administration and class naming. Class names must "
"be unique within their owning schemas.") ]
class Meta_Schema:Meta_NamedElement
{
};

// ==================================================================
// Trigger
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"A Trigger is a recognition of a state change (such as create, delete, "
"update, or access) of a Class instance, and update or access of a "
"Property.") ]
class Meta_Trigger:Meta_NamedElement
{
};

// ==================================================================
// Qualifier
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Qualifier class represents characteristics of named elements. "
"For example, there are qualifiers that define the characteristics of a "
"property or the key of a class. Qualifiers provide a mechanism that "
"makes the Metaschema extensible in a limited and controlled fashion."
"<P>It is possible to add new types of qualifiers by the introduction of "
"a new qualifier name, thereby providing new types of metadata to "
"processes that manage and manipulate classes, properties, and other "
"elements of the Metaschema.") ]
class Meta_Qualifier:Meta_NamedElement
{
[Description ("The Value property indicates the value of the qualifier.")]
string Value;
};

// ==================================================================
// Method
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Method class represents a declaration of a signature; that is, "
"the method name, return type and parameters, and (in the case of a "
"concrete class) may imply an implementation.") ]
class Meta_Method:Meta_NamedElement
{
};

// ==================================================================
// Property
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Property class represents a value used to characterize "
"instances of a class. A property can be thought of as a pair of Get and "
"Set functions that, when applied to an object, return state and set "
"state, respectively.") ]
class Meta_Property:Meta_NamedElement
{
};

// ==================================================================
// Reference
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Reference class represents (and defines) the role each object "
"plays in an association. The reference represents the role name of a "
"class in the context of an association, which supports the provision of "
"multiple relationship instances for a given object. For example, a "
"system can be related to many system components.") ]
class Meta_Reference:Meta_Property
{
};

// ==================================================================
// Class
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Class class is a collection of instances that support the same "
"type; that is, the same properties and methods. Classes can be arranged "
"in a generalization hierarchy that represents subtype relationships "
"between classes.<P>The generalization hierarchy is a rooted, directed "
"graph and does not support multiple inheritance. Classes can have "
"methods, which represent the behavior relevant for that class. A Class "
"may participate in associations by being the target of one of the "
"references owned by the association.") ]
class Meta_Class:Meta_NamedElement
{
};

// ==================================================================
// Indication
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Indication class represents an object created as a result of a "
"trigger. Because Indications are subtypes of Meta_Class, they can have "
"properties and methods, and be arranged in a type hierarchy. ") ]
class Meta_Indication:Meta_Class
{
};

// ==================================================================
// Association
// ==================================================================
[Version( "2" ), Revision( "2" ), Description (
"The Meta_Association class represents a class that contains two or more "
"references and represents a relationship between two or more objects. "
"Because of how associations are defined, it is possible to establish a "
"relationship between classes without affecting any of the related "
"classes.<P>For example, the addition of an association does not affect "
"the interface of the related classes; associations have no other "
"significance. Only associations can have references. Associations can "
"be a subclass of a non-association class . Any subclass of "
"Meta_Association is an association.") ]
class Meta_Association:Meta_Class
{
};

// ==================================================================
// Characteristics
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Aggregation, Description (
"The Meta_Characteristics class relates a Meta_NamedElement to a "
"qualifier that characterizes the named element. Meta_NamedElement may "
"have zero or more characteristics.") ]
class Meta_Characteristics
{
[Description (
"The Characteristic reference represents the qualifier that "
"characterizes the named element.") ]
Meta_Qualifier REF Characteristic;
[Aggregate, Description (
"The Characterized reference represents the named element that is being "
"characterized.") ]
Meta_NamedElement REF Characterized;
};

// ==================================================================
// PropertyDomain
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Aggregation, Description (
"The Meta_PropertyDomain class represents an association between a class "
"and a property.<P>A property has only one domain: the class that owns "
"the property. A property can have an override relationship with another "
"property from a different class. The domain of the overridden property "
"must be a supertype of the domain of the overriding property. The "
"domain of a reference must be an association.") ]
class Meta_PropertyDomain
{
[Description (
"The Property reference represents the property that is owned by the "
"class referenced by Domain.") ]
Meta_Property REF Property;
[Aggregate, Description (
"The Domain reference represents the class that owns the property "
"referenced by Property.") ]
Meta_Class REF Domain;
};

// ==================================================================
// MethodDomain
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Aggregation, Description (
"The Meta_MethodDomain class represents an association between a class "
"and a method.<P>A method has only one domain: the class that owns the "
"method, which can have an override relationship with another method "
"from a different class. The domain of the overridden method must be a "
"supertype of the domain of the overriding method. The signature of the "
"method (that is, the name, parameters and return type) must be "
"identical.") ]
class Meta_MethodDomain
{
[Description (
"The Method reference represents the method that is owned by the class "
"referenced by Domain.") ]
Meta_Method REF Method;
[Aggregate, Description (
"The Domain reference represents the class that owns the method "
"referenced by Method.") ]
Meta_Class REF Domain;
};

// ==================================================================
// ReferenceRange
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Description (
"The Meta_ReferenceRange class defines the type of the reference.") ]
class Meta_ReferenceRange
{
[Description (
"The Reference reference represents the reference whose type is defined "
"by Range.") ]
Meta_Reference REF Reference;
[Description (
"The Range reference represents the class that defines the type of "
"reference.") ]
Meta_Class REF Range;
};

// ==================================================================
// QualifiersFlavor
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Aggregation, Description (
"The Meta_QualifiersFlavor class represents an association between a "
"flavor and a qualifier.") ]
class Meta_QualifiersFlavor
{
[Description (
"The Flavor reference represents the qualifier flavor to "
"be applied to Qualifier.") ]
Meta_QualifierFlavor REF Flavor;
[Aggregate, Description (
"The Qualifier reference represents the qualifier to which "
"Flavor applies.") ]
Meta_Qualifier REF Qualifier;
};

// ==================================================================
// SubtypeSupertype
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Description (
"The Meta_SubtypeSupertype class represents subtype/supertype "
"relationships between classes arranged in a generalization hierarchy. "
"This generalization hierarchy is a rooted, directed graph and does not "
"support multiple inheritance.") ]
class Meta_SubtypeSupertype
{
[Description (
"The SuperClass reference represents the class that is hierarchically "
"immediately above the class referenced by SubClass.") ]
Meta_Class REF SuperClass;
[Description (
"The SubClass reference represents the class that is the immediate "
"descendent of the class referenced by SuperClass.") ]
Meta_Class REF SubClass;
};

// ==================================================================
// PropertyOverride
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Description (
"The Meta_PropertyOverride class represents an association between two "
"properties where one overrides the other.<P>Properties have reflexive "
"associations that represent property overriding. A property can "
"override an inherited property, which implies that any access to the "
"inherited property will result in the invocation of the implementation "
"of the overriding property. A Property can have an override "
"relationship with another property from a different class.<P>The domain "
"of the overridden property must be a supertype of the domain of the "
"overriding property. The class referenced by the Meta_ReferenceRange "
"association of an overriding reference must be the same as, or a "
"subtype of, the class referenced by the Meta_ReferenceRange "
"associations of the reference being overridden.") ]
class Meta_PropertyOverride
{
[Description (
"The OverridingProperty reference represents the property that overrides "
"the property referenced by OverriddenProperty.") ]
Meta_Property REF OverridingProperty;
[Description (
"The OverriddenProperty reference represents the property that is "
"overridden by the property reference by OverridingProperty.") ]
Meta_Property REF OverriddenProperty;
};

// ==================================================================
// MethodOverride
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Description (
"The Meta_MethodOverride class represents an association between two "
"methods, where one overrides the other. Methods have reflexive "
"associations that represent method overriding. A method can override an "
"inherited method, which implies that any access to the inherited method "
"will result in the invocation of the implementation of the overriding "
"method.") ]
class Meta_MethodOverride
{
[Description (
"The OverridingMethod reference represents the method that overrides the "
"method referenced by OverriddenMethod.") ]
Meta_Method REF OverridingMethod;
[Description (
"The OverriddenMethod reference represents the method that is overridden "
"by the method reference by OverridingMethod.") ]
Meta_Method REF OverriddenMethod;
};

// ==================================================================
// ElementSchema
// ==================================================================
[Association, Version( "2" ), Revision( "2" ), Aggregation, Description (
"The Meta_ElementSchema class represents the elements (typically classes "
"and qualifiers) that make up a schema.") ]
class Meta_ElementSchema
{
[Description (
"The Element reference represents the named element that belongs to the "
"schema referenced by Schema.") ]
Meta_NamedElement REF Element;
[Aggregate, Description (
"The Schema reference represents the schema to which the named element "
"referenced by Element belongs.") ]
Meta_Schema REF Schema;
};

2. Values for UNITS Qualifier