Default, Empty, and Null Values
As a general rule, optional elements can be omitted from any QDoc if the requestor wants the target QAD application to use their default values. A particularly important special case of this rule is the modify or change operation of a CRUD request. If an element in a modify/change request is omitted, the QAD application presumes that the element’s value should not be changed and retains its existing value. This approach has the major advantage of conciseness, as it permits the requestor to populate the QDoc request with only the content that is relevant and omit the rest.However, this approach does raise the problem of ambiguity with respect to empty values. If an omitted element signifies that its default value should be used, how do you communicate a request inside a QDoc to blank out the element’s value? In other words, how should an empty value be represented? The term empty instead of null is used in order to avoid confusion with the concept of a special null object/value, such as Java null or the Progress unknown value. Unlike the null value, empty values vary based on data type. For character fields empty would be a null string, for numbers the value zero, and for logicals the value false.To distinguish between default and empty values in QDoc requests, a distinction is made in all QDocs between an omitted element and an empty-valued one. If an element is omitted, the QAD application uses its default value. If it is empty valued (that is, has the form or ), the application assumes that the element should be assigned the empty value appropriate for its type.While XML schema allows null elements to be explicitly represented with a nil attribute, enabled by a nillable attribute in the respective elements’ schema definition, use of this construct, and null values in general, is not supported by the QDoc schemas as a general rule. However, the nil and nillable attributes may be designated for use in special cases where QAD application processing requires null value input.