HP WBEM Services Software Developer's Kit for HP-UX Provider and Client Developer's Guide A.01

Schema Design and Implementation
Schema Design
Chapter 338
• Try to place the property as high in the class hierarchy as possible
while maintaining appropriate meaning. Note that changes to the
DMTF schema need to be worked through an appropriate DMTF
working group as discussed in MOF File Content Guidelines below.
• Consider if the property would still make sense in a lower subclass
derived at some point in the future.
• Make sure that qualifiers on the property (those special attributes
characterizing a property, see the DMTF web site on qualifiers) are
all necessary and sufficient; important qualifiers such as
"Description" will ensure that there is a common understanding of
the property between clients and providers.
• Consider what values a property will hold across various platforms.
Providers on various operating systems and platforms could choose
different values for properties in instrumenting similar objects. Will
this implementation create confusion for client applications? Does
there need to be a clearer Description of a property or a whitepaper
to clarify a property's usage?
• Consider the client need to identify resources shared across multiple
servers as being the same (making shared resources both
cluster-aware and SAN-aware). If two servers share some resource
(for example a disk array, backup device, or SAN element), is it
important that a management client managing both platforms be
able to identify that the resource being modeled is in fact the same
resource? If so, it may be important to ensure that the definition of
one or more properties ensures an easy recognition of the common
resource (for example a common GUID or a serial number property).
Key Properties
One or more properties for a given class are specified as being key
properties via the Key qualifier. Key properties are used to uniquely
identify each instance of a given class within a namespace. A CIM class
cannot redefine (change, add to, or delete from) key properties defined in
a superclass. For the most common case, where a given class is derived
from a DMTF class which already has keys defined, key identification is
trivial. However, in some rare cases where a high-level, "non-keyed" class
is used for inheritance, definition of key properties is necessary. Care
must be taken to ensure that theproperties are defined in a way that will
facilitate that uniqueness and ensure interoperability across multiple
platforms (for example IA-32, IPF, PA-RISC, Sparc).