The following abstract comes from the W3C XML Namespace Recommendation:
"XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by Universal Resource Identifier (URI) references."
The XML Namespaces 1.0 Recommendation is available at
http://www.w3.org/TR/REC-xml-names/. Please see
http://www.w3schools.com/xml/xml_namespaces.asp for more information on the basics of XML namespaces.
XML Namespaces provide a way to avoid ambiguity with XML tags (does
<table> refer to a table of data, or a pyhsical wood table?) Namespaces can be specified either with a default namespace that applies to an entire block or schema, or by defining prefixes that are a shorthand that can be applied to individual tags.
Timport has two modes of operation regarding namespaces when processing XML, namespace-aware and namespace-unaware. By default, timport is unaware of namespaces.
xmlns attributes are treated just like any other attribute, and the namespace prefixes are not given any special consideration - the tag
<myPrefix:tagName> must be matched as exactly that, regardless of what URI
myPrefix resolves to. In versions prior to 5.01.1120676700 (July 7 2005), this was the only mode available.
If one or more namespaces are provided in the schema (via
xmlns commands, see page here), then timport becomes namespace-aware. When comparing a XML tag to a field's tag, timport will first compare the namespaces, and if those match, then it compares tag names (sans namespace prefixes). For example, with the following XML document:
With the following schema:
# name type tag default_val
field orderID long orders/order/orderID 0
In the XML, the prefix
mc is defined, and all tags are given that prefix, therefore they all belong to the
http://www.mycompany.com namespace. In the schema file,
http://www.mycompany.com is defined as the default namespace, so all of the elements in
orders/order/orderID are also part of the
For the first comparison, the XML document's
<mc:orders> and the schema's
orders, they are both found to be in the same namcepace. It then compares the tags, disregarding any namespace prefix (since we already know the namespaces match). After stripping off any prefixes, it compares XML's
orders to the schema's
orders, which match, so it continues.
You can use prefixes in schemas too. The following schema will match the xml document exactly the same way as the previous schema will:
field orderID long myComp:orders/myComp:order/myComp:orderID
Note that although the prefixes are different (
myComp), they both resolve to the same URI, and therefore are part of the same namespace.
Please see the examples (page here) below for more examples of using XML namespaces.