Why is it better to statically resolve XML QNames than to dynamically resolve XML QNames?

Question

A QName is a namespace-qualified name. Here is XML containing two QNames:

<ac:aircraft xmlns:ac="http://www.aircraft.org">
    <ac:altitude>12,000 feet</ac:altitude>
</ac:aircraft>

The two abbreviated QNames are:

ac:aircraft
ac:altitude

The expanded QNames are:

{http://www.aircraft.org}aircraft
{http://www.aircraft.org}altitude

XML parsers know the rules for converting short names (abbreviated names) to long names (expanded names).

The abbreviated form of the names are statically -- at parse time -- resolvable to the long names.

QNames may also be used in data. In the following XML, the value of the <log> element is a QName:

<network-traffic xmlns:network="http://www.network-traffic.org">
      <log>network:client-error</log>
</network-traffic>

XML parsers operate only on markup, not data. So, an XML parser does not convert the short name to the long name. The mapping from short name to long name must be done by a higher level application such as an XSLT processor or an XML Schema validator. In other words, the resolution of short name to long name must be done dynamically, not statically.

Question: Why is it better to statically resolve short names to long names? What are the disadvantages of dynamically resolving short names to long names? Can you provide a concrete example of where problems arise as a result of having to dynamically resolve short names to long names? What are the practical benefits to static analysis of QNames?

Answer 1

I think Micheal's point is that namespace prefixes should be viewed as a lexical convenience. The real qualified name is a (namespace,name) pair, not a (prefix, name) pair. A single namespace might be represented using several different prefixes, even within the same document.
The distinction often does not matter. If the namespace bindings are available then it's trivial to convert from a prefix to a namespace. However, some developers get lazy and write code that depends on particular namespace prefixes. That's a fragile strategy, because if one part of the XML info set gets copied elsewhere then the hierarchy of namespace bindings may change, and the meaning of those prefixes could also change. To guard against this, applications that process XML info sets should not offer APIs that provide direct access to the prefix ( unless for the purpose of manipulating the prefix-to-namespace bindings ). Instead, the info set should contain the full namespace for every node. If you've ever called an XPath processor from within a program then you may have encountered this problem. XPath is prefix-aware, and it's often necessary to set up a 'namespace context' object for the XPath processor before executing an XPath expression. Otherwise the prefixes in the XPath expression can get interpreted incorrectly.