The Disposition of Names in an XML Namespace

DRAFT TAG Finding 13 September 2005

This version:
Latest version:
Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>

This document is also available in these non-normative formats: XML.


This Finding addresses the question of whether or not adding new names to a (published) namespace is a sound practice.

Status of this Document

This document has been produced for review by the W3C Technical Architecture Group (TAG). This finding addresses TAG issue nameSpaceState-48.

This document is an editor's draft without any normative standing.

Additional TAG findings, both accepted and in draft state, may also be available.

The terms MUST, SHOULD, and SHOULD NOT are used in this document in accordance with [RFC 2119].

Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org (archive).

Table of Contents

1 Preface
2 Namespace Definitions
3 References

1 Preface

Namespaces are a mechanism for managing names in a distributed way that greatly reduces the likelihood that two independent parties will create the same name for different resources.

The terms in a namespace are two-part identifiers consisting of a namespace name, a URI, and a local name (an NCName as defined in [XML Namespaces]). Using a URI leverages the well-understood URI allocation mechanisms of [WebArch Vol 1].

The proposed definition of a new local name “id” in the xml: namespace raised a question about the identity of a namespace. Concretely, one perspective was that the xml: namespace consisted of xml:space, xml:lang, and xml:base (and no other names) because there was a point in time in which those where the only three names from that namespace that had a defined meaning. Another perspective was that the xml: namespace consisted of all possible local names and that only a finite (but flexible) number of them are defined at any given point in time.

2 Namespace Definitions

The publication of [xml:id] as a Recommendation, provides a partial answer to the question of which perspective is correct. Adding the local name “id” to the xml: namespace demonstrates that the xml: namespace evolves according to the latter position.

The question remains, however, as to whether the former position is ever sound. This Finding takes the position that it is.

Namespaces, originally designed to provide names for XML elements and attributes, have been adopted much more broadly by the web community. They are now used not simply for elements and attributes but for function names, tokens, and identifiers for an ever expanding class of resources.

The xml: namespace demonstrates that some namespaces benefit from a policy that allows additional names to be defined in them over time. This does not seem to preclude the possibility that some namespaces would benefit from a policy that forbids such extension. From these observations, we conclude that the following good practice applies:

Good Practice

Specifications that define namespaces SHOULD explicitly state their policy with respect to changes in the names defined in that namespace. For namespaces that are not immutable, they SHOULD describe how names may be added (or removed) and by whom.

3 References

RFC 2119
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF. March, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
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/.)
WebArch Vol 1
Ian Jacobs and Norman Walsh, editors. Architecture of the World Wide Web, Volume 1. World Wide Web Consortium, 2004. (See http://www.w3.org/TR/webarch/.)
Jonathan Marsh, Daniel Veillard, and Norman Walsh, editors. xml:id Version 1.0. World Wide Web Consortium, 2005. (See http://www.w3.org/TR/xml-id/.)