W3C Recommendation 16 August 2006
- This version:
- http://www.w3.org/TR/2006/REC-xml-names-20060816
- Latest version:
- http://www.w3.org/TR/xml-names
- Previous version:
- http://www.w3.org/TR/2006/PER-xml-names-20060614
- Editors:
- Tim Bray, Textuality <tbray@textuality.com>
- Dave Hollander, Contivo, Inc. <dmh@contivo.com>
- Andrew Layman, Microsoft <andrewl@microsoft.com>
- Richard Tobin, University of Edinburgh and Markup Technology Ltd <richard@cogsci.ed.ac.uk>
Please refer to the errata for this document, which may include some normative corrections.
See also translations.
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Abstract
XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references.
Status of this Document
W3C technical reports index at http://www.w3.org/TR/.
This document is a product of the XML Core Working Group as part of the W3C XML Activity. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names .
Known implementations are documented in the Namespaces 1.1 implementation report (all known Namespaces 1.1 implementations also support Namespaces 1.0) . A test suite is also available via the XML Test Suite page.
This second edition incorporates all known errata as of the publication date. It supersedes the previous W3C Recommendation of 14 January 1999 .
Please report errors in this document to xml-names-editor@w3.org; public archives are available. The errata list for this document is available at http://www.w3.org/XML/2006/xml-names-errata .
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Motivation and Summary
We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a "markup vocabulary") that are defined for and used by multiple software modules. One motivation for this is modularity: if such a markup vocabulary exists which is well-understood and for which there is useful software available, it is better to re-use this markup rather than re-invent it.
Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the elements and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element name or attribute name.
expanded names to elements and attributes.
1.1 A Note on Notation and Usage
Note that many of the nonterminals in the productions in this specification are defined not here but in the XML specification [XML]. When nonterminals defined here have the same names as nonterminals defined in the XML specification, the productions here in all cases match a subset of the strings matched by the corresponding ones there.
In this document's productions, the NSC is a "Namespace Constraint", one of the rules that documents conforming to this specification MUST follow.
2 XML Namespaces
2.1 Basic Concepts
[RFC3986]; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]
[Definition: In either case the local name is N. ] It is this combination of the universally managed IRI namespace with the vocabulary's local names that is effective in avoiding name clashes.
URI references can contain characters not allowed in names, and are often inconveniently long, so expanded names are not used directly to name elements and attributes in XML documents. Instead qualified names are used. [MUST recognize and act on these declarations and prefixes.
2.2 Use of URIs as Namespace Names
The empty string, though it is a legal URI reference, cannot be used as a namespace name.
The use of relative URI references, including same-document references, in namespace declarations is deprecated.
2.3 Comparing URI References
Definition: The two URIs are treated as strings, and they are identical if and only if the strings are identical, that is, if they are the same sequence of characters. ] The comparison is case-sensitive, and no %-escaping is done or undone.
A consequence of this is that URI references which are not identical in this sense may resolve to the same resource. Examples include URI references which differ only in case or %-escaping, or which are in external entities which have different base URIs (but note that relative URIs are deprecated as namespace names).
In a namespace declaration, the URI reference is the normalized value of the attribute, so replacement of XML character and entity references has already been done before any comparison.
Examples:
The URI references below are all different for the purposes of identifying namespaces, since they differ in case:
-
http://www.example.org/wine -
http://www.Example.org/wine -
http://www.example.org/Wine
The IRI references below are also all different for the purposes of identifying namespaces:
-
http://www.example.org/~wilbur -
http://www.example.org/%7ewilbur -
http://www.example.org/%7Ewilbur
Because of the risk of confusion between URIs that would be equivalent if dereferenced, the use of %-escaped characters in namespace names is strongly discouraged.
3 Declaring Namespaces
default. ]
Attribute Names for Namespace Declaration
| [1] | NSAttName |
::= | PrefixedAttName |
|
| DefaultAttName |
||||
| [2] | PrefixedAttName |
::= | 'xmlns:' NCName |
[NSC: Reserved Prefixes and Namespace Names] |
| [3] | DefaultAttName |
::= | 'xmlns' |
|
| [4] | NCName |
::= | NCNameStartChar NCNameChar* |
/* An XML Name, minus the ":" */ |
| [5] | NCNameChar |
::= | NameChar - ':' |
|
| [6] | NCNameStartChar |
::= | Letter | '_' |
[RFC2141] is an example of a syntax that is designed with these goals in mind. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals.
[namespace name in the attribute value in the scope of the element to which the declaration is attached. In such declarations, the namespace name may not be empty. ]
[6 Applying Namespaces to Elements and Attributes.
An example namespace declaration, which associates the namespace prefix edi with the namespace name http://ecommerce.example.org/schema:
<x xmlns:edi='http://ecommerce.example.org/schema'> <!-- the "edi" prefix is bound to http://ecommerce.example.org/schema for the "x" element and contents --> </x>
Namespace constraint: Reserved Prefixes and Namespace Names
The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace.
The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be declared . Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. Element names MUST NOT have the prefix xmlns.
All other prefixes beginning with the three-letter sequence x, m, l, in any case combination, are reserved. This means that:
-
users SHOULD NOT use them except as defined by later specifications
-
processors MUST NOT treat them as fatal errors.
Though they are not themselves reserved, it is inadvisable to use prefixed names whose LocalPart begins with the letters x, m, l, in any case combination, as these names would be reserved if used without a prefix.
4 Qualified Names
qualified names, defined as follows:
Qualified Name
| [7] | QName |
::= | PrefixedName |
| UnprefixedName |
|||
| [8] | PrefixedName |
::= | Prefix ':' LocalPart |
| [9] | UnprefixedName |
::= | LocalPart |
| [10] | Prefix |
::= | NCName |
| [11] | LocalPart |
::= | NCName |
LocalPart provides the local part of the qualified name.]
Note that the prefix functions only as a placeholder for a namespace name. Applications SHOULD use the namespace name, not the prefix, in constructing names whose scope extends beyond the containing document.
5 Using Qualified Names
qualified names, as follows:
Element Names
| [12] | STag |
::= | '<' QName (S Attribute)* S? '>' |
[NSC: Prefix Declared] |
| [13] | ETag |
::= | '</' QName S? '>' |
[NSC: Prefix Declared] |
| [14] | EmptyElemTag |
::= | '<' QName (S Attribute)* S? '/>' |
[NSC: Prefix Declared] |
An example of a qualified name serving as an element name:
<!-- the 'price' element's namespace is http://ecommerce.example.org/schema --> <edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>
Attribute
| [15] | Attribute |
::= | NSAttName Eq AttValue |
|
| QName Eq AttValue |
[NSC: Prefix Declared] |
An example of a qualified name serving as an attribute name:
<x xmlns:edi='http://ecommerce.example.org/schema'> <!-- the 'taxClass' attribute's namespace is http://ecommerce.example.org/schema --> <lineItem edi:taxClass="exempt">Baby food</lineItem> </x>
This constraint may lead to operational difficulties in the case where the namespace declaration attribute is provided, not directly in the XML document entity, but via a default attribute declared in an external entity. Such declarations may not be read by software which is based on a non-validating XML processor. Many XML applications, presumably including namespace-sensitive ones, fail to require validating processors. If correct operation with such applications is required, namespace declarations MUST be provided either directly or via default attributes declared in the internal subset of the DTD.
Element names and attribute names are also given as qualified names when they appear in declarations in the DTD:
Qualified Names in Declarations
| [16] | doctypedecl |
::= | '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>' |
| [17] | elementdecl |
::= | '<!ELEMENT' S QName S contentspec S? '>' |
| [18] | cp |
::= | (QName | choice | seq) ('?' | '*' | '+')? |
| [19] | Mixed |
::= | '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*' |
| '(' S? '#PCDATA' S? ')' |
|||
| [20] | AttlistDecl |
::= | '<!ATTLIST' S QName AttDef* S? '>' |
| [21] | AttDef |
::= | S (QName | NSAttName) S AttType S DefaultDecl |
Note that DTD-based validation is not namespace-aware in the following sense: a DTD constrains the elements and attributes that may appear in a document by their uninterpreted names, not by (namespace name, local name) pairs. To validate a document that uses namespaces against a DTD, the same prefixes must be used in the DTD as in the instance. A DTD may however indirectly constrain the namespaces used in a valid document by providing #FIXED values for attributes that declare namespaces.
6 Applying Namespaces to Elements and Attributes
6.1 Namespace Scoping
The scope of a namespace declaration declaring a prefix extends from the beginning of the start-tag in which it appears to the end of the corresponding end-tag, excluding the scope of any inner declarations with the same NSAttName part. In the case of an empty tag, the scope is the tag itself.
Such a namespace declaration applies to all element and attribute names within its scope whose prefix matches that specified in the declaration.
<?xml version="1.0"?>
<html:html xmlns:html='http://www.w3.org/1999/xhtml'>
<html:head><html:title>Frobnostication</html:title></html:head>
<html:body><html:p>Moved to
<html:a href='http://frob.example.com'>here.</html:a></html:p></html:body>
</html:html>
Multiple namespace prefixes can be declared as attributes of a single element, as shown in this example:
<?xml version="1.0"?> <!-- both namespace prefixes are available throughout --> <bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <bk:title>Cheaper by the Dozen</bk:title> <isbn:number>1568491379</isbn:number> </bk:book>
6.2 Namespace Defaulting
default namespace declaration extends from the beginning of the start-tag in which it appears to the end of the corresponding end-tag, excluding the scope of any inner default namespace declarations. In the case of an empty tag, the scope is the tag itself.
A default namespace declaration applies to all unprefixed element names within its scope. Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear.
If there is a default namespace declaration in scope, the expanded name corresponding to an unprefixed element name has the URI of the default namespace as its namespace name. If there is no default namespace declaration in scope, the namespace name has no value. The namespace name for an unprefixed attribute name always has no value. In all cases, the local name is local part (which is of course the same as the unprefixed name itself).
<?xml version="1.0"?>
<!-- elements are in the HTML namespace, in this case by default -->
<html xmlns='http://www.w3.org/1999/xhtml'>
<head><title>Frobnostication</title></head>
<body><p>Moved to
<a href='http://frob.example.com'>here</a>.</p></body>
</html>
<?xml version="1.0"?> <!-- unprefixed element types are from "books" --> <book xmlns='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <title>Cheaper by the Dozen</title> <isbn:number>1568491379</isbn:number> </book>
A larger example of namespace scoping:
<?xml version="1.0"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<title>Cheaper by the Dozen</title>
<isbn:number>1568491379</isbn:number>
<notes>
<!-- make HTML the default namespace for some commentary -->
<p xmlns='http://www.w3.org/1999/xhtml'>
This is a <i>funny</i> book!
</p>
</notes>
</book>
The attribute value in a default namespace declaration MAY be empty. This has the same effect, within the scope of the declaration, of there being no default namespace.
<?xml version='1.0'?> <Beers> <!-- the default namespace inside tables is that of HTML --> <table xmlns='http://www.w3.org/1999/xhtml'> <th><td>Name</td><td>Origin</td><td>Description</td></th> <tr> <!-- no default namespace inside table cells --> <td><brandName xmlns="">Huntsman</brandName></td> <td><origin xmlns="">Bath, UK</origin></td> <td> <details xmlns=""><class>Bitter</class><hop>Fuggles</hop> <pro>Wonderful hop, light alcohol, good summer beer</pro> <con>Fragile; excessive variance pub to pub</con> </details> </td> </tr> </table> </Beers>
6.3 Uniqueness of Attributes
In XML documents conforming to this specification, no tag may contain two attributes which:
This constraint is equivalent to requiring that no element have two attributes with the same expanded name.
For example, each of the bad empty-element tags is illegal in the following:
<!-- http://www.w3.org is bound to n1 and n2 --> <x xmlns:n1="http://www.w3.org" xmlns:n2="http://www.w3.org" > <bad a="1" a="2" /> <bad n1:a="1" n2:a="2" /> </x>
However, each of the following is legal, the second because the default namespace does not apply to attribute names:
<!-- http://www.w3.org is bound to n1 and is the default --> <x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" > <good a="1" b="2" /> <good a="1" n1:a="2" /> </x>
7 Conformance of Documents
In XML documents which conform to this specification, element and attribute names MUST match the production for QName and MUST satisfy the "Namespace Constraints". All other tokens in the document which are REQUIRED, for XML 1.0 well-formedness, to match the XML production for Name MUST match this specification's production for NCName.
[Definition: A document is namespace-well-formed if it conforms to this specification. ]
It follows that in a namespace-well-formed document:
-
All element and attribute names contain either zero or one colon;
-
No entity names, processing instruction targets, or notation names contain any colons.
In addition, a namespace-well-formed document may also be namespace-valid.
[NCName. ]
It follows that in a namespace-valid document:
-
No attributes with a declared type of ID, IDREF(S), ENTITY(IES), or NOTATION contain any colons.
8 Conformance of Processors
To conform to this specification, a processor MUST report violations of namespace well-formedness, with the exception that it is not REQUIRED to check that namespace names are legal URIs.
Definition: A validating XML processor that conforms to this specification is namespace-validating if in addition it reports violations of namespace validity. ]
A Normative References
- Keywords
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, ed. IETF (Internet Engineering Task Force), March 1997. Available at http://www.rfc-editor.org/rfc/rfc2119.txt
- RFC2141
- RFC 2141: URN Syntax, R. Moats, ed. IETF (Internet Engineering Task Force), May 1997. Available at http://www.rfc-editor.org/rfc/rfc2141.txt.
- RFC3986
- RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), January 2005. Available at http://www.rfc-editor.org/rfc/rfc3986.txt
- RFC3629
- RFC 3629: UTF-8, a transformation format of ISO 10646, F. Yergeau, ed. IETF (Internet Engineering Task Force), November 2003. Available at http://www.rfc-editor.org/rfc/rfc3629.txt
- XML
- Extensible Markup Language (XML) 1.0 (Fourth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau eds. W3C (World Wide Web Consortium), 16 August 2006. Available at http://www.w3.org/TR/2006/REC-xml-20060816/.
B Other references (Non-Normative)
- 1.0 Errata
- Namespaces in XML Errata. W3C (World Wide Web Consortium). Available at http://www.w3.org/XML/xml-names-19990114-errata.
- Relative URI deprecation
- Results of W3C XML Plenary Ballot on relative URI References In namespace declarations 3-17 July 2000, Dave Hollander and C. M. Sperberg-McQueen, 6 September 2000. Available at http://www.w3.org/2000/09/xppa.
D Changes since version 1.0 (Non-Normative)
There are several editorial changes, including a number of terminology changes and additions intended to produce greater consistency. The non-normative appendix "The Internal Structure of XML Namespaces" has been removed.
E Acknowledgements (Non-Normative)
This work reflects input from a very large number of people, including especially the participants in the World Wide Web Consortium XML Working Group and Special Interest Group and the participants in the W3C Metadata Activity. The contributions of Charles Frankston of Microsoft were particularly valuable.