Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
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.
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.
1 QNames in Namespaces in XML
2 QNames in Other Specifications
3 Architectural Observations
4 Architectural Recommendations
5 References
Qualified names (QNames) were introduced by [XML Namespaces]. They were defined for element and attribute names (only) and provided a mechanism for concisely identifying a URI/localname 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/localname pair they identify.
Other specifications, starting perhaps with [XSLT], have taken QNames and employed them in other contexts. Specifically, QNames have been used in element content and attribute values.
In these contexts, QNames are most often used to identify a particular element type; they are, in principal using QNames as they were intended.
It's possible that specifications will invent new uses for QNames as well, using them as shortcuts for unique identifiers derived from a URI/localname pair that have no relationship to element or attribute types.
The TAG makes the following observations:
Whatever architectural ramifications this usage may have, it is already established practice.
Using QNames in untyped (#PCDATA or
xs:string) attribute values or element content places an additional
burden on the processor that was not anticipated by [XML Namespaces].
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, so things aren't quite this simply for most developers if serialization is involved, but this is still the theoretical 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 QName and need to find its URI/localname.
QNames in attribute values or element content by
themselves, in other words, in contexts that could be typed as
xs:QName in an schema, could in principal be identified by
the processor.
The TAG recognizes that there are pragmatic reasons why it is desireable to provide the same kind of URI/localname 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 carefully the ramifications of the use of QNames in other contexts on the complexity of processors for their grammars. Where possible, limiting their use to attribute values and simple element content that can be identified as having a QName type may ultimately reduce the complexity.