background image
Functional specification
99
CDE/Motif PST
CDEnext
7.2
Attribute Value Defaulting And Validation
This section provides an overview of default attribute values and validation of attribute values within the X Print
Service. Details for individual attributes can be found in the rest of this chapter.
7.2.1
Defaulting Attribute Values
An attribute specification with an empty value shall indicate that the attribute has no value. Within X Print Service
configuration files and attribute pools, an attribute specification that omits the value is effectively treated as if there
is no attribute specification. An empty valued attribute specification that has precedence over a non-empty attribute
specification (for instance, an empty printer qualified attribute over a non-empty model qualified attribute) will
effectively "unset" the lower precedence attribute specification. When a print job commences, the X Print Service
may infer a default value for an attribute that has no value. In some cases the X Print Service may explicitly assign
a default value to an attribute before presenting it in an attribute pool.
The ISO DPA provides for explicitly assigning
generic-none
to an attribute in order to prevent any action
implied for that attribute; however this implementation of the X Print Service does not recognize
generic-none
for any of the attributes it defines.
7.2.2
Validation of Attribute Values
The X Print Server (in conjunction with the print ddx drivers) ensures that attribute pools presented to the client are
always comprised of valid attribute specifications, for attributes defined by the X Print Service. Validation is first
performed when a print context is created for a particular printer. Validation is also performed whenever a client
requests an update to an attribute pool.
Validation involves checking the attribute value against the set of valid values specified for the attribute. Validation
may also take into account the current values of other attributes and the capabilities of the ddx driver.
At print context creation time, if the server determines that an attribute value is invalid, its course of action is
determined based upon whether the attribute has a single value or a multiple value. For single valued attributes the
server will reject the invalid attribute specification, and may decide to set an explicit default for the attribute in the
pool. For multi-valued attributes, the server will reject each value component that is invalid. If all of the specified
components are invalid, the server will reject the attribute specification, and for certain attributes will set an explicit
default for the attribute in the pool.
When the client requests an update to an attribute pool (e.g. when calling
XpSetAttributes
), if the server
determines that an attribute value is invalid, its course of action is the same as at print context creation time, with
one exception; in the cases where the server would choose to use a default, the server will instead retain the pre-
existing attribute specification found in the pool.
The server will provide log messages when invalid attributes are encountered when constructing an attribute pool.
Print clients will not receive notification of invalid attribute specifications. Interested clients must re-read the
attribute pool to determine if the requested value was accepted by the server.
It is important to note that as part of the validation for a given attribute a ddx driver may choose to alter other
attributes in response to the change. For example one can imagine that changing the value of the
document-
format
attribute would cause the value of the
xp-embedded-formats-supported
attribute to change as
well. In spite of the fact that the sample implementation does not do this for any attribute, applications should be
prepared for the value of an attribute to change in response to the changing of some other attribute's value.