The Heading Tab contains fields that are used to fill in information in the header table of a Change Request XML file.



CR Number

The number of this Change Request. the last five (5) characters must be numeric while the preceding must be one or more alphabetic characters; e.g. DIAG00100. For the DMTF, Change Requests are created by members of a DMTF Working Group. A Working Group may define a prefix to be used for the Change Requests that they submit. For example, the Diagnostics WG uses the DIAG prefix. Each Working Group uses a document number reservation mechanism to ensure that all of their Change Requests are uniquely numbered. The mechanism works as follows:

Description

A short description for the change being requested that clearly describes the change(s) made. Its composition should be sufficiently worded so that it can be easily included in the README for the changes to the next schema release.

Author Name

The name of the author for this change request.

Author E-Mail

The email address of the author for this change request.

Alliance Org

For DMTF change requests, leave this field blank. Otherwise, select the organization submitting the change request from the pull-down list.

Alliance Data

For DMTF change requests, leave this field blank. Otherwise, the author should provide Alliance-specific information about the change request. The information could be the Alliance-specific identifier, tracking number, vote history or any other information the author wishes to provide.

Errata

Select Yes if the proposed change is solely editorial. For example, to fix misspellings or typographical errors.

Date Originated

The date that the change request was first created.

Date Modified

The date of the current change request. This date will be the same as the Date Originated only when creating a new class.

Dependencies

There are two common cases where values should be entered in the Dependencies field:
    1. When Class A is defined as subclass of Class B, then the CR for Class B must be processed before the CR for Class A. Otherwise, the MOF compiler cannot successfully create Class A. The CR for Class A should list the CR number and class name for Class B as a dependency. However, the CR for Class B need not list the CR number and class name for Class A as a dependency.
    2. When association Class AB has a reference to newly defined Class A and Class B, then the CRs for Class A and Class B must be processed before the CR for class AB. Otherwise, the MOF compiler cannot successfully create association Class AB. The CR for association Class AB should list the CR numbers and class names for Class A and Class B as dependencies. However, the CRs for Class A and Class B need not list the CR number and class name for association class AB as a dependency. See the example below.
    3. When the extrinsic method of Class A has a reference parameter to newly defined class B, then the CR for Class B must be processed before the CR for Class A. Otherwise, the MOF compiler cannot successfully create Class A. The CR for Class A must list the CR and class name for Class B as a dependency. However, The CR for Class B need not list the CR and class name for Class A as a dependency.


This example shows that CORE000498 and CORE00499 must be processed before CORE00500.


The example shows that DIAG00055 (CIM_RAIDDiagnosticSettingData) is dependent upon DIAG00054 (CIM_RAIDDiagnosticTest) and DIAG00056 (CIM_RAIDDiagnosticServiceCapabilities). In addition, DIAG00054 should list DIAG00055 and DIAG0056 as dependencies. Likewise, DIAG00056 should list DIAG00054 and DIAG00055 as dependencies.