Schema Implementation

In addition to the DMTF-specified syntax for MOF files as described in the CIM specification and the guidance provided by the DMTF MOF Style Guide, additional factors should be considered for the development, testing, and on-going maintenance of MOF files.

MOF File Content Guidelines

MOF is the standard format for defining CIM objects. HP WBEM Services for HP-UX includes a MOF compiler for loading of schema into the CIM Server's repository (please see the man page for the cimmof command, as well as discussion below). Tasks that can be performed through loading MOF file via the CIM Server's MOF compiler include: (1) defining classes (and associated superclasses), (2) defining qualifiers, and (3) creating instances of classes.

Class/Superclass Definitions
Classes, along with their associated superclasses, are defined in MOF files. All superclasses should be included in the schema definition. Order of definition is important, so superclasses must be defined prior to their subclasses (no forward referencing). When referencing DMTF-defined objects, include the class definitions verbatim.
Changes to DMTF classes are implemented through the DMTF change request (CR) process, and so should not be implemented ad hoc by a provider implementer. HP WBEM Services for HP-UX is installed with DTMF CIM v2.5 preloaded in the root/cimv2 namespace.
Qualifiers
Generally speaking, there is no need to define additional qualifiers via MOF files. Use of the existing DMTF-defined qualifiers is sufficient. Qualifiers are defined during the creation of each namespace in the CIM Server's repository and should not be redefined in MOF files.
A full list of the qualifiers and their definitions can be found on the DMTF web site, http://www.dmtf.org.
Instance Definitions
Instances can be defined in MOF. The result of these definitions is that a provider supporting instances of the class receives a request to create an instance with the values specified in the MOF file.

Registering Providers

The CIM Server associates classes with the providers that instrument them through instances of the Provider Registration classes in the special root/PG_InterOp namespace: PG_Provider, PG_ProviderModule, and PG_ProviderCapabilities. An example is shown in the section on “Provider Registration and Naming”. While provider registration instances are conveniently specified in MOF, they should be in a different file than the one used to specify the schema definition so that these different components can be managed separately.

Note that the provider registration mechanism of HP WBEM Services for HP-UX eliminates difficulties encountered with the Provider qualifier. These include:

Requires modification of schema definition (which is in principle improper if the schema being modified is part of the DMTF-supplied CIM schema)
Does not distinguish between an Instance and an Association provider for an association class
Does not permit more than one provider to a class
Cannot specify supported properties or methods

HP WBEM Services for HP-UX ignores the Provider qualifier if present.

Rules for Updating Schema

There are several considerations when either planning or implementing an upgrade to a previously released MOF file.

Backward Compatibility

It is very important to consider backward compatibility when upgrading a MOF file because CIM clients may continue operation before and after a MOF/provider upgrade. Causes of failures in applications due to upgrades include (but are not limited to):

Deletion of a class, property, or method
Movement of a class within the hierarchy in any direction except "down" as a side effect of a new superclass being inserted in the line of descent above
Changing a property's type or a method's signature (method type, parameter type, names of parameters, number of parameters)
Decreasing Max or increasing Min cardinalities of associations

A detailed specification of changes which cause a major revision to the CIM schema, and thus can affect applications, can be found in the section labeled Schema Versions in the latest CIM Specification on the DMTF web site: http://dmtf.org.

Note that the DMTF CIM schema will never shrink through the life of a major version (for example Version going from CIM v2.6 to CIM v2.7). It continues to grow due to this upgrade strategy.

Deprecation

Deprecation and use of the Deprecate qualifier is the appropriate route for dealing with classes, properties, and methods within the schema for which there is a plan to discontinue support in the future. While within a major version of the CIM schema (for example Version 2.x), the Deprecate qualifier signals that the entity will no longer be available in a future major release (for example Version 3.x). The class, property, or method should continue to be supported until the future release but the qualifier indicates that there is a preferred alternative in place (the parameter of the Deprecate qualifier).

Discontinuing Support

When upgrading to a new major version of the CIM schema, it is possible to discontinue support for a capability implemented in the schema through a class, property, or method. A major release (for example from Version 2.x to Version 3.x) is most likely placed within a different namespace, reducing compatibility issues between clients and providers. Because it is difficult to synchronize installation of clients and providers, clients would need to support both the old schema and the new schema.

Discontinuing support on a minor version changed within a major version (for example Version 2.x to Version 2.y, where x < y) is not recommended, as discussed in “Backward Compatibility ” above. However, it could be accomplished if a provider could be certain that all clients using the class, property, or method were upgraded simultaneously with the provider. This is very difficult to ensure and is not recommended.

Class "Version" qualifiers

The DMTF uses the major and minor version numbers to reflect which version of the CIM schema originated a class. The format for class version numbers is "m.n.u" where:

m = major version (numeric)
n = minor version (numeric)
u = update (errata or DMTF coordinated changes) (numeric)

In CIM Schema version 2.6, for example, the major version number is 2 and the minor version number is 6. For more information, see the section labeled Schema Versions in the latest CIM Specification.

When upgrading a provider, it is important to be sure that all affected classes (those which are extensions created by the provider implementer) have their version number incremented appropriately. When defining additional subclasses, provider developers can use version numbers associated with their product as long as they conform to the syntax described in the list above. It is important to be sure that the major version number is only incremented when major revisions are made to the schema (those possibly breaking backward compatibility). Incrementing the minor version indicates that the schema upgrade will not adversely impact client applications. The update number can be used for internal changes relative to a defined (probably released) baseline. The Version qualifier for the class should only be changed if the class definition is changed. Developers can use whatever version numbers they'd like as long as they comply with the rules stated above.

Superclasses Shared with Other Providers

Extensions to the DMTF CIM schema which result in superclasses that are shared among providers must be handled carefully when considering a MOF file upgrade. If changes to these shared classes must be implemented, coordination among those sharing the class is essential. The "owner" of the shared class must coordinate changes between the affected parties and adhere to the upgrade policies described above. The newest version (with correct version number) of the class should be used with a new release of any of the MOFs which all share the same superclass.