This TAG Finding documents a portion of the web architecture where conflicting requirements and design goals intersect. It is a simple matter of fact that specifications which have chosen one set of design criteria interoperate less well with specifications that have chosen a different set.

Given that there are existing specifications which exhibit incompatible designs and strong arguments in favor of each design, the TAG elects not to assert architectural principles that would be in direct conflict with some significant set of specifications.

It's possible that these issues could be addressed in the scope of some larger, more global redesign of, for example, XML, but no short-term solution presents itself

This finding is concerned with the use of qualified names (QNames) as identifiers. That is, the contexts in which a colonized name can be understood to be a QName.

A related TAG issue, rdfmsQnameUriMapping-6, concerns the mechanism by which one can (or can not) construct a URI for a particular QName. We do not consider that issue in this finding.

Qualified names were introduced by . They were defined for element and attribute names (only) and provide a mechanism for concisely identifying a URI/local-name pair. For example, in the following document:

The QName x:p is a concise, unambiguous name for the URI/local-name pair {"http://example.com/ns/foo", "p"}.

When used solely in element and attribute names, all QNames are identified by the XML processor and can logically be replaced by the URI/local-name pair they identify.

Other specifications, starting with , have taken QNames and employed them in contexts other than element and attribute names. Specifically, QNames have been used in attribute values and element content.

For example, in the following document, x:p is understood to be a QName even though it appears in an attribute value, not an element or attribute name.

In attribute values and element content, QNames are often used to identify a particular element type; they are, in principle, using QNames as they were intended. However, some specifications use QNames as shortcuts for unique identifiers derived from a URI/local-name pair that have no relationship to element or attribute types.

Using a QName as a shortcut for a URI/local-name pair is often convenient, but it carries a price. There is no single, accepted way to convert QNames into URI/local-name pairs or vice versa. Different specifications have chosen different algorithms. This means that even if a QName can be identified in content, it may be difficult or impossible to determine what URI/local-name it represents. At the very least, the mapping depends on the context in which it occurs. Therefore, at the very least, it is important for specifications to identify the mapping algorithm that they have chosen.

Specifications that use QNames to represent URI/local-name pairs MUST describe the algorithm that is used to map between them.

We observe also that there is an overlap in the lexical space of QNames and URIs.

Specifications that use QNames to represent URI/local-name pairs SHOULD NOT allow both forms in attribute values or element content where they would be indistinguishable.

Some specifications rely on the in-scope namespace bindings in the XML document to associate prefixes with namespace names. Other specifications rely on application-specific mechanisms.

Using the in-scope namespace bindings has the advantage that it theoretically allows a generic processor to interpret QNames in content without having to be aware of any application-specific mechanisms. The alternative, where every specification defines its own mechansism, could clearly lead to a badly fragmented web.

However, there is at least one application where a compelling argument has been made for requiring an alternative mechanism for defining namespace bindings. That application is .

It is an architectural principle of URIs that they be context-independent. It follows that the QNames that appear in an XPointer must not refer to in-scope namespaces as this would make transcription impossible in the general case.

We must therfore accept that there are some applications which use in-scope namespaces and some which use their own mechanisms.

The TAG makes the following observations:

The TAG recognizes that there are pragmatic reasons why it is desireable to provide the same kind of URI/local-name shortcuts that QNames provide for element and attribute names in other contexts. In addition, the practice is already well established. Therefore, the TAG accepts that it is reasonable to use QNames in this way.

Specifications that have no compelling reason to use QNames where URIs would suffice, for example formats that are not expected to be edited by hand or formats where human readability is not a significant factor, can avoid an entire set of problems by simply using URIs.

The TAG encourages designers to consider the ramifications of their use of QNames carefully as it may have a dramatic impact on the extent to which their specification interoperates with other specifications.