As mentioned before, a single XML field on the transport side is represented on the correlator side as a series of name/value fields, all prefixed by the value you specified for the XMLField property. This section describes how the XML codec names fields, based on the XML data.

Note, any field not specified as an XMLField for the XMLCodec will pass through the system as normal. These fields are not dropped/ignored.

If there is any uncertainty about the correct transport field names to use in the IAF mapping rules, try setting the logFlattenedXML codec property to true.

To preserve XML node ordering information, the codec adds ordering information to node names by appending a suffix according to the suffix generation mode enabled — either "", "#2", "#3", and so on or "[1]", "[2]", "[3]", and so on.

The "#n" sibling format provides a total ordering across all child nodes under a given parent, specifying each node's position relative to all of its sibling nodes. This suffix mode is the default. To turn it off, set the generateSiblingOrderSuffix codec property to false. Note that the root node never has a sibling order suffix because only one root exists. Sample field names:

The twin "[n]" format is insensitive to the order in which nodes appear as long as they have different names, and it specifies a node’s position relative to its twin nodes. (Twins are siblings with the same node name.) This suffix mode is disabled by default (for backwards compatability). To turn it on, set the generateTwinOrderSuffix codec property to true. To improve readability the first sibling node with a given name has no suffix. That is, the [1] suffix is implicit. Sample field names:

Note that for a message to be correctly translated in the upstream direction (from the correlator), there do not have to be enough suffixes in the event to form a total order, but any suffixes that are provided will be used. In the absence of sibling order suffixes to determine ordering of different node types, the XML codec generates the XML nodes in the following order:

The XML codec maps XML elements, attributes, CDATA and text data as described in the following sections. In the following topics, assume that the value of the XMLField property is Test.

An XML element maps to a field with the following characteristics:

For example, an element B nested inside an element A is represented in the normalised event as follows:

When the XML codec generates XML for upstream events, it is not a requirement to have an associated field for every element. The XML codec automatically creates ancestor XML elements when they do not have associated fields. For example, consider the following field:

If necessary, the codec creates the A and B element nodes.

XML element attributes map to fields with names equal to the parent element's field name, followed by '@att' where att is the name of the attribute, and the field's value is the attribute value. For example, an attribute B of an element A with the value Hello is represented as follows:

XML CDATA in an element maps to a field with a name equal to the parent element's field name followed by CDATA() and a value that contains the text data. For example, an element A with CDATA " Hello " followed by sub-element B followed by CDATA " World " is represented as follows:

Text data in an XML element maps to a field with a name equal to the parent element's field name followed by text(). The value of the field is the text data. Unless the trimXMLText is false (the default is that it is true), the codec strips leading and trailing whitespace from text data. For example, an element A that contains the text " Hello World " followed by sub-element B followed by text " ! " is represented as follows:

In the event of errors during XML parsing, the parser