XML messages in the MRM and XML domains !!

If your messages are in XML, you can use either the XML Wire Format in the MRM domain, or one of the dedicated XML domains. Three XML domains are supported. The XMLNSC and XMLNS domains provide namespace support, but the XML domain does not support XML namespaces and is provided only for compatibility with WebSphere MQ Integrator Version 2.

Whether you choose the MRM domain, or one of the dedicated XML domains (XMLNSC or XMLNS), depends on the nature of your XML messages and the transformation logic that you want to use. The differentiating features of each domain are described below.

* The parser for the MRM domain is model-driven, using a message dictionary that is generated from a message set. This message dictionary enables the MRM parser to interpret the data in an XML message.
For example:
o The MRM parser can validate XML messages against the model when parsing and serializing.
o The model indicates the real data type of a field in the message instead of always treating it as a character string.
o Base64 binary data can be automatically decoded.
o Date and time information can be extracted from a data value using a specified format string.
o When creating output messages, the MRM parser can automatically generate the XML declaration, and other XML constructs, based on options in the model; this simplifies the transformation logic.
* The parsers for the XMLNSC and XMLNS domains are programmatic and do not use a model when parsing.

For example:
o All data in an XML message is treated as character strings.
o Validation is not possible when parsing and serializing.
o Transformation logic must create explicitly all constructs in an output message.
o Both parsing and serializing are quicker than with the MRM domain.
* The MRM parser discards some parts of an XML message when parsing; for example, the XML declaration, namespace declarations, white space formatting, XML comments, XML processing instructions, and inline DTDs. If you use this parser, you cannot create these constructs when building an output message.
* The XMLNSC parser, by default, discards white space formatting, XML comments, XML processing instructions, and inline DTDs. However, options are provided to preserve all of these constructs, except inline DTDs. You can create them all, except inline DTDs, when constructing an output message.
* The XMLNS parser preserves all parts of an XML document, including white space formatting. You can create all XML constructs when constructing an output message.
* The MRM and XMLNSC parsers build compact message trees that use fewer syntax elements than the XMLNS parser for attributes and simple elements, thus making these parsers more suitable for parsing very large XML messages.
* The XMLNS parser builds a message tree that conforms more closely to the XML data model. You might want to use this parser if you are using XPath to access the message tree, and the relative position of parent and child nodes is important, or if you are accessing text nodes directly.

Tip: If you need to validate the content and values in XML messages, use the MRM domain.

Tip: If performance is critical, and you do not need to validate XML messages, use the XMLNSC domain.

Tip: If you need to preserve formatting in XML messages on output, use the XMLNSC domain with the option to retain mixed content.

Tip: If you are using XPath to access the message tree, and you require the message tree to conform as closely as possible to the XML data model, use the XMLNS domain.

Tip: If you are taking non-XML data that has been parsed by the CWF or TDS formats of the MRM domain, and transforming the data to the equivalent XML, use the MRM domain.