TAG Finding: Using Qualified Names (QNames) as Identifiers in Content

TAG Draft 17 Jun 2002

This version:
http://www.w3.org/2001/tag/doc/qnameids (HTML, XML)
Previous versions:
http://www.w3.org/2001/tag/doc/qnameids-2002-06-04 http://www.w3.org/2001/tag/doc/qnameids-2002-04-30
Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>


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.

Status of this Document

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.

Comments may be directed to the W3C TAG mailing list www-tag@w3.org (archive).

Publication of this document by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.

Table of Contents

1 QNames as Identifiers
2 QNames in XML
    2.1 Prefixes in Other Contexts
3 QNames in Other Specifications
4 Architectural Observations
5 Architectural Recommendations
6 References

1 QNames as Identifiers

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.

2 QNames in XML

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">

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.

2.1 Prefixes in Other Contexts

At the request of the XML Schema Working Group, the XML Core Working Group is producing an erratum to [XML Namespaces] to clarify the meaning of colons in other contexts.

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.

3 QNames in Other Specifications

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 attribute name.

<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

<xsl:output method="html"/>

<xsl:template match="x:p">


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.

4 Architectural Observations

The TAG makes the following observations:

5 Architectural Recommendations

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. In particular, it makes the following recommendations.

  1. Specifications should not introduce QNames into mixed content or attribute values with untyped string content.

  2. Specifications should not introduce union types that include xs:QName as a possible component.

  3. Specifications should not use tokens that are syntactically QNames (that match the QName production) unless they are also semantically QNames.

  4. Specifications describing an XML language must not introduce new namespace declaration or scoping rules.

  5. Element or attribute values that contain a single QName should be declared with the xs:QName type.

6 References

XML Namespaces
Tim Bray, Dave Hollander, Andrew Layman, editors. Namespaces in XML. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/REC-xml-names/.)
James Clark, editor. XML Transformations (XSLT) Version 1.0. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/xslt.)
XML Datatypes
Paul V. Biron and Ashok Malhotra, editors. XML Schema Part 2: Datatypes. World Wide Web Consortium, 2000. (See http://www.w3.org/TR/xmlschema-2/.)