Message model objects: simple type value constraints

Value constraints refine a simple type by defining limits on the values which it can represent.

It is often useful to be able to constrain the values which an element can take, perhaps to ensure that messages conform to business rules. This topic describes how value constraints can be added to a simple type in order to constrain the values of all elements based on it.

Most of the value constraints discussed here are modeled by XML Schema facets, and are associated with a simple type. However, default values and fixed values can be defined for an element, and these are associated with the element itself.

Tip: If the message set is deployed to WebSphere Message Broker, all value constraints can be validated, so that any violations will be reported as errors or warnings.

Types of value constraint

Default Value
If an empty element is present in an input message, it will be assigned the default value. If an element is completely missing from an input message, it will not be assigned any value at all.

If an attribute is missing from an input message, it will be assigned the default value.

Note that default value constraints are associated with the element itself, and therefore cannot be inherited.

Note: If you deploy a message set to WebSphere Message Broker, the behavior described above will not always apply. For details of the differences, refer to the Relationship to the logical model topic for the appropriate physical format.
Fixed Value
If an element appears in an input message, its value must be the specified fixed value. If an empty element is present in an input message, it will be assigned the fixed value. If an element is completely missing from an input message, it will be assigned the fixed value.

If an attribute is present in an input message, it must have the fixed value. If an attribute is missing from an input message, it will be assigned the fixed value.

Fixed value constraints are associated with the element itself, and therefore cannot be inherited.

Note: If you deploy a message set to WebSphere Message Broker, the behavior described above will not always apply. For details of the differences, refer to the Relationship to the logical model topic for the appropriate physical format.
Length Constraints : Length, Min Length, Max Length
Using length constraints, the length of all elements based on the simple type can be constrained or even limited to a single value.

Length constraints can be applied to simple types which are derived from xsd:hexBinary, xsd:base64Binary or xsd:string (including built in schema types such as xsd:normalisedString).

Length constraints are inherited from ancestor types, and any length constraints defined for a simple type must not relax the constraints imposed by any of its ancestor types. For example, it would be illegal to derive a type 'longString' (Max Length=100) from a type 'shortString' (Max Length=10).

Note: For WebSphere Message Broker by default, Length value constraints are converted to Max Length constraints when a message set is added to a BAR file. This avoids WebSphere Message Broker raising spurious validation errors for fixed-length data structures, where the strings tend to be padded to fit a fixed-width field. If strict length validation is required, this default can be changed in the message set properties by changing the flag Broker treats Length facet as MaxLength.
Range constraints : Min Inclusive, Max Inclusive, Min Exclusive, Max Exclusive
Range constraints specify the allowable range of values for all elements which are based on the simple type. Inclusive constraints include the specified endpoints in the allowed range, whereas exclusive constraints do not. Range constraints can be applied to simple types which are numerical or which relate to calendar and time values. They cannot be applied to strings, because the ordering of string values depends on the character set being used.

Range constraints are inherited from ancestor types, and any range constraints defined for a simple type must not relax the constraints imposed by any of its ancestor types. For example, it would be illegal to derive a type 'largeNumber' (Max Inclusive=100) from a type 'smallNumber' (Max Inclusive=10).

The message model does not allow exclusive constraints to be applied to non-integral types (float, decimal, double, dateTime, and so on).

Enumeration constraints
An enumeration constraint specifies a single allowed value for all elements which are based on the simple type. A list of allowed values can be specified by defining more than one enumeration constraint for the same simple type. Enumeration constraints can be applied to all simple types.

Enumeration constraints are inherited from ancestor types, and any set of enumeration constraints defined for a simple type must not increase the range of allowed values. For example, it would be illegal to derive a type 'AllColours' (with enumerations for all colours of the rainbow) from a type 'MonoColours' (with enumerations for 'black' and 'white' only).

Precision constraints : Total Digits and Fraction Digits
Precision constraints relate only to decimal values. They limit the number of significant digits (total digits) and the number of decimal places (fraction digits) for all elements based on the simple type. Precision constraints can only be applied to simple types which are derived from xsd:decimal.

Precision constraints are inherited from ancestor types, and any precision constraints defined for a simple type must not relax the constraints imposed by any of its ancestor types. For example, it would be illegal to derive a type 'veryPrecise' (Fraction Digits=10) from a type 'notVeryPrecise' (Fraction Digits=1).

Pattern constraints
A pattern constraint is a regular expression specifying a set of allowed values for all elements based on the simple type. Multiple patterns can be defined for the same simple type, allowing complex validation rules to be expressed in logically separate parts. Each pattern constraint on a simple type contributes to the set of allowed values for elements based on it. In other words, all the patterns are combined using Boolean OR.

As with all value constraints, a simple type can inherit pattern constraints from the simple type on which it is based. In this case, the set of pattern constraints contributed by each ancestor type must be satisfied as well as the set contributed by the simple type itself. In other words, the sets of pattern constraints from each level in the type hierarchy are combined using Boolean AND.

Pattern constraints can only be applied to simple types which are derived from xsd:string.

Whitespace constraints
A whitespace constraint specifies how a parser should treat whitespace for all elements based on the simple type.
Note: For WebSphere Message Broker, the MRM physical formats allow whitespace to be controlled very precisely for each physical format defined for the message, but these physical properties are separate from the whitespace constraint in the logical model.