MRM model restrictions

This topic provides information on areas where the WebSphere MQ Integrator Broker does not exactly follow the XML Schema specification.

XML Schema features supported only in the message editor

The following features can be created and edited using the message editor, but are not honored by WebSphere Message Broker:

  • Pattern facet on non-string data types. The message broker will only validate pattern facets which are applied to simple types based on xsd:string.
  • Whitespace facet. The message broker does not make use of the whitespace facet at all (although whitespace facets can be included in the message model if necessary). It is possible to accurately control the processing of whitespace using the settings on the physical formats.
  • ID attribute. The message model can contain attributes with the name 'id', but these will not be checked for uniqueness.

XML Schema exceptions

The following features may be created and edited using the message editor, but the message broker will process them in a way which differs from the XML Schema specification, as follows:

  • Default and fixed values. The processing of default and fixed values depends on the physical format in which the message is parsed. For details on how each physical format uses these fields, refer to the concept topic Relationship to the logical model for the relevant physical format.
  • xsi:type attribute. The xsi:type attribute is not automatically processed by the message broker. An attribute with the name 'xsi:type' can be included in the message model, and can be processed using a message flow.

Differences in validation

If validation is enabled in a message flow, the following features/scenarios will not be validated in exactly the same way as a validating XML parser would validate them:

  • Any Element/Any Attribute. If the message model contains a wildcard ('any element' or 'any attribute') the message broker will validate the 'processContents' field as follows:
    • skip. No checking will be done, any element/attribute will be allowed.
    • lax. No checking will be done, any element/attribute will be allowed.
    • strict. Any element/attribute in the same message set will be allowed.
    Note: If all of the definitions for a namespace are included within the same message set, the validation of 'strict' will be the same as a validating XML parser.
  • Element substitution and 'all' groups. If an element is substitutable, and it occurs within an 'all' group, the following exceptions apply to the validation of the element:
    • A substitutable element within an 'all' group will always be validated as if it were optional.
    • An input message will not be rejected if more than one of the substitutions is used in the same 'all' group.