Namespace support

The XPath Expression builder provides qualified support for namespaces.

The XPath Expression builder dialog contains a namespace settings table that:
  • Supports simplified expressions that enable qualified namespace matching at run time
  • Can be auto-generated based on imported schema definitions and generated expressions (based on selections made in the dialog when you build an expression)
  • Allows you to add your own entries to the table

The table encapsulates deployable data passed to the runtime environment, as part of the nodes attribute data, and is used by the node to modify expressions through prefix-to-URI substitution. The final expressions support namespace matching, because they are processed against a target tree when employed by their associated message processing engine, that is, the XPath 1.0 runtime engine or ESQL runtime engine.

When you enter an ESQL field reference expression in a read-only or read-write path field, or an XPath 1.0 path expression in a read-only or read-write path field, or a general expression field (general expressions can contain zero or more path expressions), IBM® Integration Bus understands the language from the syntax you use.

XPath is the default for general expression fields that are validated by ensuring they conform to the XPath 1.0 grammar. For path expression fields XPath is assumed if the expression is valid and begins with a $ sign.

The language you can use is dictated by the property editor currently in use for a node's property field.

Namespace prefixes are used in an XPath or ESQL expression to make the statements shorter and easier to understand, while still supporting the ability to qualify an element name match by also matching on its associated namespace URI.

For example, consider the following message, where namespace prefix b is overridden through an inner declaration:
 <b:a xmlns:b='xyz'>
  <!-- the namespace of elements 'a' and 'c' using prefix 'b'  is xyz -->
  <b:c>
   <b:d  xmlns:b='qrs'>
    <!-- the namespace of elements 'd' and 'e' using prefix 'b' is now qrs -->
    <b:e>100</b:e>
   </b:d>
  </b:c>
 </b:a>

Note that the scope of a namespace declaration declaring a prefix extends from the beginning of the start tag in which it appears to the end of the corresponding end tag, excluding the scope of any inner declarations with the same namespace prefix. In the case of an empty tag, the scope is the tag itself: >.

To navigate to element e in the above message use the following human-readable XPath expression:
  /b:a/b:c/b2:d/b2:e

Note, that to prevent the auto-generated prefix to the URI map produced in the expression dialog overloading the same prefix (in this case b), the inner b prefix is appended with a numeric value to distinguish it from the outer b prefix. This strategy is repeated for each prefix name clash.

This notation is similar to the equivalent human-readable ESQL expression:
  Root.b:a.b:c.b2:d.b2:e

To support namespace prefixes within expressions, the XPath Expression Builder Dialog automatically generates a prefix to a URI namespace settings table (based on the content of imported schema definitions, through which expressions are generated) .

Without the use of namespace prefixes to URI mapping data in this table, the runtime environment would be forced to take a less efficient approach, where portable but verbose XPath expressions would be required by it to provide namespace matching support.

The previous expression:
  /b:a/b:c/b2:d/b2:e
would take the form:
  /*[namespace-uri()='xyz' and local-name()='a']/*[namespace-uri()='xyz' 
     and local-name()='c']/*[namespace-uri()='qrs' and 
     local-name()='d']/*[namespace-uri()='qrs' and local-name()='e']