The question (see issue qnameAsId-18) that prompted this finding was "are QNames acceptable replacements for URIs as identifiers within specifications?" This finding documents the TAG's opinion on the use of QNames as identifiers.
This document has been developed for discussion by the W3C Technical Architecture Group.
This document is the work of the editor. It is a draft with no official standing. It does not necessarily represent the consensus opinion of the TAG.
Publication of this document by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
2 QNames as Identifiers
3 QNames in XML
3.1 Prefixes in Other Contexts
4 QNames in Other Specifications
5 Namespace Bindings
6 Architectural Observations
7 Architectural Statement
This TAG finding makes no recommendations. It exists to document 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 has elected simply to highlight this area rather than assert archtectural 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 [XML Namespaces]. 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:
<?xml version='1.0'?> <doc xmlns:x="http://example.com/ns/foo"> <x:p/> </doc>
The QName "
x:p" is a concise, unambiguous
name for the URI/local-name pair
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.
In particular, this erratum makes it clear that entity names, processing instruction targets, and notation names are not QNames and they may not include any colons. Documents that do not satisfy this constraint are not namespace well-formed. Furthermore, the values of attributes of type ID, IDREF(S), ENTITY(IES), and NOTATION are also forbidden from containing colons. Documents that do not satisfy this constraint are not namespace valid.
A colon that introduces a namespace validity or namespace well-formedness error into a document does not introduce a QName. In other words, the term "identifier" in this finding is not related to XML identifiers of type ID since they cannot be QNames.
Other specifications, starting with [XSLT], have taken QNames and employed them in contexts other than element and attrbiute 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
<?xml version='1.0'?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:x="http://example.com/ns/foo" version="1.0"> <xsl:output method="html"/> <xsl:template match="x:p"> <p> <xsl:apply-templates/> </p> </xsl:template> </xsl:stylesheet> </doc>
In attribute values and element content, QNames are most often used to identify a particular element type; they are, in principle, using QNames as they were intended.
Other specifications use QNames as shortcuts for unique identifiers derived from a URI/local-name pair that have no relationship to element or attribute types.
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 [XPointer Framework].
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:
Whatever the architectural ramifications of using QNames as identifiers in contexts other than XML element and attribute names, it is already established practice.
It is simply not practical to suggest that this usage should be forbidden on architectural grounds.
Using QNames in untyped (
xs:string) attribute values or element
content places an additional burden on the processor
that was not anticipated by [XML
If QNames are only used in element and attribute names, the processor can fully resolve all of the prefixes as it parses. This gives it the freedom to discard the prefix-to-URI mappings when they go out of scope. A serializer, presented with an object model that conforms to [XML Namespaces] can manufacture new prefixes on the fly. (In practice, users expect most prefixes to be preserved through transformations, so things aren't quite this simple for most developers, but this is still theoretically the case.)
As soon as QNames may appear in element or attribute values, the processor must retain all of the prefix-to-URI mappings (and any API must expose these mappings). This is necessary because some subsequent micro-parser, in the course of examining some content, may encounter a token that it recognizes as a QName and need to find its URI/local-name.
In our previous XSL example, from the perspective of
the XML processor, there are no qualified names that
x: prefix. However, when the
XSL processor examines the
xsl:template, it must be able
to resolve the
QNames in attribute values or element content by
themselves, in other words, in contexts that could
be typed as
xs:QName ([XML Datatypes]) in a schema, could
in principle be identified by the schema processor.
For example, given:
If schema validation reveals that the following
component applies to this instance of the
<xs:complexType name="elemType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="ref" type="xs:QName"/> </xs:restriction> </xs:complexContent> </xs:complexType>
The schema processor can determine that
data:myInteger is a QName and must
therefore be a concise name for the URI/local-name pair
consisting of the in-scope namespace URI for the prefix
data and the local-name
Perhaps the most common use of QNames in untyped values at the moment is in locations where XPath expressions may occur. As XPath is reused in more and more specifications, it may eventually be reasonable to define an XPath data type to identify all of these values in a way that makes them accessible to higher-level parsers.
Some specifications rely on mechanisms other than in-scope namespaces to associate prefixes with namespace names. In general, therefore, even when all of the in-scope namespace declarations are available, there may still be prefixes which can only be known in an application-dependent manner.
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.
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.