Namespaces in the message model

Use namespaces to qualify message model object names.

A single XML instance document can contain elements and attributes that are defined for, and possibly used by, multiple applications. Two different elements or attributes within the same document might require the same name. Individual applications must be able to recognize the elements and attributes that they are designed to process. In circumstances such as this, the definitions can be distinguished from each other by qualifying each element with a different namespace. This avoids problems of name collision and mistaken recognition.

XML Schemas can define a target namespace. Global elements, attributes, groups, and types that are defined within an XML Schema are qualified by the target namespace, if it has been defined. Optionally, local elements and attributes can also be qualified by the target namespace. Therefore, namespaces assist in the development of a library of XML Schemas that can be developed independently. If the namespace name that is used for an XML Schema is unique, you do not have to be concerned about name clashes with objects that are defined within other XML Schemas.

The scope of a namespace extends beyond the scope of its containing document and is identified by a Uniform Resource Identifier (URI). In order to serve its purpose, a URI must be unique. You might be more familiar with the concept of a Universal Resource Locator (URL). URIs often use the same syntax as URLs, but the URI definition is broader than the specification of a URL. This is an example of a URI: http://mycompany.com/xml_schema

A namespace prefix is declared as a shorthand for the full URI name and this is used to qualify all elements that belong to that namespace. The prefix to be substituted for a namespace in an XML instance document or XML Schema is specified by using an xmlns attribute. A default namespace can also be defined by using an xmlns attribute. If a default namespace is defined, any element or attribute with no prefix is qualified with the default namespace. If no default namespace is defined, any element or attribute with no prefix is not qualified by a namespace.

Namespaces and the message model
Message model schema files in applications or libraries, and message definition files in message sets, support namespaces.

A single application, library, or message set can contain a number of different namespaces. Each namespace is represented by a different message model schema file or message definition file. When you create a file, you can choose whether it has an associated namespace, or whether it is in the notarget namespace. If you associate a namespace, you must also choose a prefix.

If the file has an associated namespace, the following global objects are qualified with the namespace:

  • Elements
  • Attributes
  • Simple Types
  • Complex Types
  • Groups
  • Attribute Groups

Optionally, local elements and attributes can be qualified with the namespace.

Objects that are defined in a file can reference objects in other files. To create these references, import or include one file within another file. A message model schema file can import or include another file in the same application or library, or in a separate IBM® App Connect Enterprise library. A message definition file can import or include another file only if it is in the same message set.

Message parsing and message flows
IBM App Connect Enterprise parsers for XML data recognize prefixed names in the XML messages that they parse, and internally map these to the correct namespace. The message tree stores the name and the namespace of the element or attribute.

Namespaces can be used even when the data is not XML. DFDL schema, Adapter schema, and message definition files can be created with an associated target namespace. Though the data itself does not contain prefixed names, the namespace is obtained from the corresponding element in the file. Again, the message tree stores the name and the namespace of the element.

You can specify namespaces when writing ESQL or Java™. It is not necessary to write ESQL or Java that is namespace aware if you are not using namespaces. However, if you decide to use namespaces it is necessary to write namespace-aware ESQL or Java. The namespace in which an element is contained is stored in the message tree when parsed. This is a logical property and it is held regardless of the physical wire format in which messages are parsed and written. Syntax has been added to ESQL to make it easy to reference namespaces of other elements by using defined prefixes. In Java, XPath expressions are used to reference elements.