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:
- Login to the DMTF website
- Click on the Members Area link at the top of the home page
- Select the Working Group (e.g. DIAG SIG)
- Select the Documents link for the Working Group
- Select the Change Requests folder in the left pane
- Select Actions / Add Document in the right pane
- Click on Reserve a Number and the next unused Change Request
number will be selected
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:
- When one CR for a class definition must be processed before the
CR of another class definition can be processed. There are three common
scenarios when this may occur.
- 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.
- 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.
- 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.
- When changes to more than one class must be submitted together.
For example, the set of classes may be logically related to each other
because they are defined as part of a new profile specification.
Frequently, ModelCorrespondence qualifiers for properties in one class
refer to a properties in other dependent classes. Enter the CR number
and class name of the other dependent classes as a comma separated
list. Order is not important for this case.

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.