Rational Developer for System z

Namespaces

XML instance documents and XML Schemas can make use of namespaces. Namespaces provide a method to qualify artifact 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 artefacts 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 URL's, 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 attribute. A default namespace can also be defined 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 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 file (also called a message definition file). When you create a message 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 file you must also choose a prefix.

If the message file has an associated namespace the following global artefacts 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.

Artifacts defined within a message file can reference artefacts in other message files within the same message set. This is achieved by importing or including one message file within another.

The XML Wire Format

The namespace associated with a message file (also called 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 files with their prefixes when they were created.

Message parsing and ESQL

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.

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 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 files (also called message definition files) from other formats by importing them into the message model. If you import from a COBOL Copy book, a C Header file or XML DTD file the message file created will be in the notarget namespace. When you import XML Schema file the target namespace of the created message file depends on whether namespaces have been enabled for the message set. If namespaces are enabled the target namespace of the message file created by the import will be the target namespace of the XML Schema being imported.

However if namespaces are disabled for the message set the created message file will be in the notarget namespace irrespective of the target namespace of the XML Schema file being imported. This type of import does not provide full namespace support. The action of the importer in this instance are described in more detail in the Importing from XML Schema concept topic.

Further information about XML


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)