WebSphere Message Broker, Version 8.0.0.7
Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS
See information about the latest product version
See information about the latest product version
MRM restrictions
The MRM parser does not exactly follow the XML Schema 1.0 specification.
However, the XMLNSC domain fully complies with the XML Schema 1.0 specification when validation is enabled. All of the constructs that are mentioned in this topic are supported by the XMLNSC domain.
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 the MRM domain.
- Pattern facet on non-string data types. The message broker only validates pattern facets that are applied to simple types based on xsd:string.
- White space facet. The message broker does not use the white space facet. However, if necessary, white space facets can be included in the message model. You can accurately control the processing of white space by 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 can be created and edited using the message editor, but the MRM domain processes them in a way that differs from the XML Schema specification.
- 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 or scenarios are not validated in exactly the same way as a validating XML parser would validate them:
- Any Element or Any Attribute. If the message model contains
a wildcard ('any element' or 'any attribute'), the message broker
validates the 'processContents' field as follows:
- skip. No checking is done; any element or attribute is allowed.
- lax. No checking is done; any element or attribute is allowed.
- strict. Any element or attribute in the same message set is allowed.
Note: If all of the definitions for a namespace are included within the same message set, the validation of 'strict' is the same as by a validating XML parser. - Element substitution and 'all' groups. If an element can
be substituted, and it occurs within an 'all' group, the following
exceptions apply to the validation of the element:
- The element is always validated as if it were optional.
- An input message is not rejected if more than one of the substitutions is used in the same 'all' group.