]>
The Disposition of Names in an XML Namespace &http-ident;-&iso6.doc.date; TAG Finding &draft.day; &draft.monthname; &draft.year; &http-ident;-&iso6.doc.date; XML &http-ident; &http-ident;-2005-12-16 Norman Walsh Sun Microsystems, Inc. Norman.Walsh@Sun.COM

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

This document has been produced by the W3C Technical Architecture Group (TAG). This finding addresses TAG issue nameSpaceState-48. The TAG approved this finding at its 3 January 2006 teleconference. Additional TAG findings, both approved and in draft state, may also be available.

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

The terms MUST, SHOULD, and SHOULD NOT are used in this document in accordance with .

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

Chicago, Vancouver, Mountain View, et al.: World-Wide Web Consortium, Draft TAG Finding, 2005.

Created in electronic form.

 English 2005-09-13: Published draft
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 purposes.

An XML namespace has a namespace name (a URI) and a set of local names (NCNames as defined in ). Using a URI leverages the well-understood URI allocation mechanisms of . defines a syntactic shorthand for the combination of a namespace name and a local name: the qualified name, or “QName”. (Note that languages which use QNames as identifiers are required to provide a mapping from QNames to URIs.)

The proposal to define a new local name, “id”, in the namespace “http://www.w3.org/XML/1998/namespace” (the xml: namespace) raised a question about the identity of a namespace. Concretely, it exposed two perspectives:

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.

The other 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.

Colloquially, we often speak of “adding a name” to a namespace. Here we prefer to speak of “defining a name” or otherwise licensing the interpretation of a name. For example, the specification defines the meaning of the local name “id” in the xml: namespace. Similarly, a namespace created to hold the names of all the reserved words in a programming language would license the interpretation of those QNames without explicitly defining each of them.

 Namespace Definitions

The publication of as a Recommendation, provided a partial answer to the question of which perspective is correct. Adding a definition for the local name “id” in the xml: namespace demonstrated that the number of local names defined in the xml: namespace could be extended.

The question remains, however, as to whether the other 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 ever more purposes.

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

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, the specification SHOULD describe how names may be given definitions (or have them removed) and by whom.

If a namespace document is provided, as recommends, the namespace change policy SHOULD be stated in the namespace document.

As a general rule, resources on the web can and do change. In the absence of an explicit statement, one cannot infer that a namespace is immutable.

References S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF. March, 1997. Tim Bray, Dave Hollander, Andrew Layman, editors. Namespaces in XML. World Wide Web Consortium, 1999. Ian Jacobs and Norman Walsh, editors. Architecture of the World Wide Web, Volume 1. World Wide Web Consortium, 2004. Jonathan Marsh, Daniel Veillard, and Norman Walsh, editors. xml:id Version 1.0. World Wide Web Consortium, 2005.