Which XML parser should you use?

If your messages are general-purpose XML documents, you can use one of the dedicated XML domains (XMLNSC or XMLNS) to parse the message, or you can use the MRM domain to parse the message.

Note: Although SOAP XML can be parsed using any namespace-aware XML parser, use the dedicated SOAP domain to parse SOAP XML because the SOAP domain provides full support for SOAP with Attachments, and standards such as WS-Addressing and WS-Security.
Note: The XML domain is deprecated. Do not use it for developing new message flows. The XML domain still works with existing message flows.

Which XML parser you choose depends on the nature of your XML messages, and the transformation logic that you want to use. The differentiating features of each domain are:

  • The XMLNSC parser has a new architecture that gives significant performance improvements over the XMLNS and XML parsers.
  • The XMLNSC parser can be used with or without an XML Schema that is generated from a message set. Using a message set with the XMLNSC parser allows the parser to operate in validating mode which provides the following capabilities:
    • XML Schema 1.0 compliant validation when parsing and writing.
    • The XML Schema indicates the real data type of a field in the message instead of always treating the field as a character string.
    • Base64 binary data can be automatically decoded.
  • The MRM parser must be used with a message dictionary that is generated from a message set. This message dictionary enables the MRM parser to provide the following capabilities: For example:
    • Validation against the dictionary when parsing and writing. Note that validation is not XML Schema 1.0 compliant.
    • The dictionary indicates the real data type of a field in the message instead of always treating the field as a character string.
    • Base64 binary data can be automatically decoded.
  • The XMLNS parser is programmatic and does not use a model when parsing.

    This means that:

    • All data in an XML message is treated as character strings.
    • Validation is not possible when parsing and writing.
  • The MRM parser uses information from the XML physical format of a message set to simplify the task of creating transformation logic:
    • Date and time information can be extracted from a data value using a specified format string.
    • When creating output messages, the MRM parser can automatically generate the XML declaration, and other XML constraints.
  • The XMLNSC and XMLNS parsers do not use XML physical format information from a message set. Transformation logic must explicitly create all constructs in an output message.
  • The MRM parser discards some parts of an XML message when parsing; for example, 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 XMLNSC and MRM parsers build compact message trees that use fewer syntax elements than the XMLNS parser for attributes and simple elements. This makes these parsers more suitable than the XMLNS parser for parsing large XML messages.
  • The XMLNS parser builds a message tree that conforms more closely than the XMLNSC or MRM parsers to the XML Data Model. You might want to use this parser if you are using certain XPath expressions to access the message tree, and the relative position of parent and child nodes is important, or if you are accessing text nodes directly.
  • The XMLNS parser holds the text content of an element as a child of the element, whereas the XMLNSC parser builds a compact tree. To update a text value in the compact tree of the XMLNSC parser, use ESQL to set the VALUE of the target node. For example:
    Set OutputRoot.XMLNSC.TestMsg.Value3 VALUE = InputRoot.XMLNSC.TestMsg.Value2;
Tip: If performance is critical, use the XMLNSC domain.
Tip: If you need to validate the content and values in 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 require the message tree to conform as closely as possible to the XML data model, perhaps because you are using certain XPath expressions to access the message tree, use the XMLNS domain.
Tip: If you are taking non-XML data that has been parsed by the DFDL domain, and merely transforming the data to the equivalent XML, use the XMLNSC domain.
Tip: If you are taking non-XML data that has been parsed by the CWF or TDS formats of the MRM domain, and merely transforming the data to the equivalent XML, use the MRM domain. You can achieve this by adding an XML physical format to the message set with default values, and changing the Message Format in the Properties folder of the message tree.