WebSphere Message Brokers
File: ad00820_
Writer: Terry Cowling

Concept topic

This build: July 31, 2007 21:21:47

Namespaces in the message model

XML instance documents and XML Schemas can make use of namespaces. Namespaces provide a method to qualify 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 need to be able to recognize the elements and attributes which 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 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. Thus namespaces assist in the development of a library of XML Schemas which can be developed independently. Providing the namespace name used for an XML Schema is unique a developer does not have to be concerned about name clashes with objects defined within other XML Schemas.

The scope of a namespace extends beyond that of its containing document and is identified by a Uniform Resource Identifier (URI). In order to serve its purpose, a URI should be unique. You might be more familiar with the concept of a Universal Resource Locator (URL). URIs often use the same syntax as URLs, although 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 belonging to that namespace. The prefix to be substituted for a namespace in an XML instance document or XML Schema is specified using an xmlns or xmlnsc attribute. A default namespace can also be defined using an xmlns or xmlnsc 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 unqualified by a namespace.

The message model
The message model provides the ability to support namespaces within message sets. However you can choose whether you wish to enable or disable namespaces for your message set. If you choose to disable namespaces when you create your message set you can enable namespaces at a some later point. However once you have enabled namespaces for a message set you cannot disable namespaces.

A single message set which has namespaces enabled can contain a number of different namespaces. Each namespace is represented by a different Message Definition File. When you create a Message Definition File you can choose whether it is to have an associated namespace or whether it is be in the notarget namespace. If you choose to associate a namespace with a Message Definition File you must also choose a prefix.

If the Message Definition 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 defined within a Message Definition File can reference objects in other Message Definition Files within the same message set. This is achieved by importing or including one Message Definition file within another.

The XML Wire Format
The namespace associated with a message definition file is part of the logical layer of the message model. Therefore it is not dependent on an XML Wire Format being present. However if you have an XML Wire Format the namespace information from the logical layer is used to populate some of the properties of the XML Wire Format. If namespaces are enabled for a Message Set, in the XML Wire Format a table of namespace URI/prefix pairs is maintained. This table is initially populated with the namespaces of all of the Message Definition Files with their prefixes when they were created.

If you are using WebSphere Message Broker and your message set has namespaces enabled, the Broker does not store the values of any xmlns or xmlnsc attributes in the tree when it parses an XML instance document. It also does not store the values of any Schema Location and No Namespace Schema Location attributes. This is because when an XML document is written out the Broker regenerates this information from the properties of the XML Wire Format of the message set.

If you are using WebSphere Message Broker the table of Namespace URI/prefix pairs is used by the MRM Domain when outputting an XML message. Elements and attributes that are qualified by a namespace are prefixed with the corresponding prefix from the table. The Broker also manages the output of the corresponding xmlns orxmlnsc attributes which map the prefixes to namespaces. You can choose whether xmlns or xmlnsc attributes for all of the entries in the Namespace URI/prefix table are output at the start of the document or whether they are only output in the document when required.

If namespaces are enabled for a Message Set, in the XML Wire Format there is a table of schema locations that map namespace URIs to file names. You can add entries to this table and you can also map a file name to the notarget namespace. If you are using WebSphere Message Broker this table is used to output schemaLocation and No Namespace Schema Location attributes at the start of the XML document.

Message parsing and ESQL
If you are using WebSphere Message Broker the MRM domain and XMLNS and XMLNSC domain parsers recognize prefixed names in the XML messages they parse and internally map these to the correct namespace. Elements and attributes in the dictionary generated from the message model can either be qualified or unqualified with a namespace as discussed in the message model section.

If you are using XML format in the MRM domain, then elements or attributes are matched based on the namespace in the dictionary when the parsed message is matched against the dictionary generated from the message model. Thus for an element or attribute in a message to match with the dictionary both its name and namespace must match.

If you are using WebSphere Message Broker, support is provided to allow you to specify namespaces when writing ESQL. It is not necessary to write ESQL which is namespace aware if you are not using namespaces. However, if you decide to use namespaces, your message definition files can target any namespace which you choose and it will be necessary to write namespace aware ESQL. The namespace in which an element resides is stored in the message tree when parsed. This is a logical property and is held regardless of the physical wire format in which messages are parsed and written. New syntax has been added to ESQL to make it easy to reference elements namespaces using defined prefixes.

Importing from other formats
The message model allows you to create Message Definition files from other formats by importing them into the Message Broker Toolkit.
  • If you import an XML DTD file the Message Definition File created will be in the notarget namespace.
  • If you import an XML Schema file, the target namespace of the created Message Definition File depends on whether namespaces have been enabled for the message set.
    • If namespaces are enabled then the target namespace of the Message Definition File created will be the target namespace of the XML Schema being imported.
    • If namespaces are disabled for the message set then the created Message Definition File will be in the notarget namespace. This type of import does not provide full namespace support. If you are using WebSphere Message Broker, you will not have to write namespace aware ESQL or Java to process an XML message parsed against the dictionary generated from this message model. For reasons why you might want to do this, see Importing XML Schema into message sets with namespaces disabled
  • If you import a COBOL Copybook or a C Header file, the target namespace of the created Message Definition File depends on whether namespaces have been enabled for the message set.
    • If namespaces are enabled then the target namespace of the Message Definition File created is the notarget namespace. This default namespace can be overridden by specifying a target namespace in the New Message Definition File wizard. For reasons why you might want to do this, see Namespaces with non-XML messages.
    • If namespaces are disabled for the message set then the created Message Definition File will be in the notarget namespace

Further information about XML

On the World Wide Web Consortium (W3C) Web site, also see:

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:21:47

ad00820_ This topic's URL is: