Pegasus Project Working Paper

Implementing NULL CIMValue Attribute

AUTHORS: Karl Schopmeyer

Last Update Monday, June 18, 2001 10:24 AM

Revision Status

Revision Date Author(s) Reason
1.0 18 June 2001 K. Schopmeyer  
       
       
       

Introduction

In reviewing the changes needed to enable the property list, it was noted that the CIM Operations over HTTP specification clearly states that the possible definitions for proertylist are:

  1. NULL - implies that the respond contains all properties.
  2. Empty list - reply with no parameters
  3. Properties listed - Respond with the properties contained in the list.

Further, NULL is the default if the propertylist parameter is not included in the request. However we are today defining an empty array as the default. In fact, we do not have the concept of NULL.

The concept of NULL is defined in the document CIM Operations over HTTP specificaion as follows

This notation uses the NULL qualifier to indicate parameters whose values may be specified as NULL in a method call. A NULL (unassigned) value for a parameter is specified by an <IPARAMVALUE> element with no subelement. For parameters which do not possess the NULL qualifier, the CIM Client MUST specify a value for the parameter by including a suitable subelement for the <IPARAMVALUE> element for that parameter.

NULL is referenced in the CIM specification as follows

4.11.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. Thus we have to be able to support the concept of NULL on any CIM type and in particular to values.

It would appear that we need to implement the concept of NULL in general on CIMValue to be compliant with the CIM specifications. Doing this will allow us to then correctly implement the NULL in the property list also. In effect, this becomes a qualifier on each CIMValue

The areas that we appear to have to change include the following:

  1. Add NULL attribute to the basic CIMValue definition.
  2. Add methods to set and test for NULL (setNull, setNotNull, isNull) to CIMValue class.
  3. Add the decoding for <IPARMVALUE> with no subelement as the decode to NULL value
  4. Add the encoding of NULL indicator on a CIMValue as <IPARMVALUE> with no subelement.
  5. Modify the set CIMValue functions -While the setNull, etc. functions can be important, the real key to making use of the NULL is through the get and set functions.   Any time a new CIMValue object is created without putting a value it in, it, it should be set NULL.  Any time a value is set in a CIMValue, the NULL attribute should be unset.
  6. Modify the get CIMValue functions - Any time an attempt is made to access a CIMValue, the value returned must depend on the state of the NULL attribute.  Since there is no value if NULL is set, we cannot return a value to the requestor if NULL is set.  Since all possible values can be returned (ex. on a Boolean CIMValue, the only possible values returned are true and false), the most logical way to inform the requester that a CIMValue is NULL is through an exception.  This is also probably the technique that causes the minimal distrubance to existing code.  THerefore, we need to throw an exception on each CIMValue get if the NULL attribute is set.
  7. Modify the propertylist processing to use NULL correctly
  8. The compiler. Not sure what Bob is doing with NULL initialization now?  However, apparently NULL is the default setting for values and in addition NULL as a property setting is specifically allowed.
  9. Clients that have been created to account for NULL in a number of cases.

NOTE: There has been some discussion of the possibility of adding the concept of  UNKNOWN to CIMValue in addition to NULL.  However, this is not in any of the specifications today and we see not reason to consider it further unless it is proposed as an extension to the CIM Specification.

---END OF DOCUMENT--