ConceptioArchiveW3C TR
W3C TRopen access

xml names

W3C · w3c_tr
W3C TR · Standards · License: Open Access
Open Source ↗
w3c, standard

Namespaces in XML 1.0 (Third Edition) code { font-family: monospace; }

div.constraint, div.issue, div.note, div.notice { margin-left: 2em; }

ol.enumar { list-style-type: decimal; } ol.enumla { list-style-type: lower-alpha; } ol.enumlr { list-style-type: lower-roman; } ol.enumua { list-style-type: upper-alpha; } ol.enumur { list-style-type: upper-roman; }

div.exampleInner pre { margin-left: 1em; margin-top: 0em; margin-bottom: 0em} div.exampleOuter {border: 4px double gray; margin: 0em; padding: 0em} div.exampleInner { background-color: #d5dee3; border-top-width: 4px; border-top-style: double; border-top-color: #d3d3d3; border-bottom-width: 4px; border-bottom-style: double; border-bottom-color: #d3d3d3; padding: 4px; margin: 0em } div.exampleWrapper { margin: 4px } div.exampleHeader { font-weight: bold; margin: 4px} This version: http://www.w3.org/TR/2009/REC-xml-names-20091208/ Latest version: http://www.w3.org/TR/xml-names/ Previous versions: http://www.w3.org/TR/2006/REC-xml-names-20060816/ http://www.w3.org/TR/2009/PER-xml-names-20090806/ Editors: Tim Bray, Textuality <[email protected]> Dave Hollander, Contivo, Inc. <[email protected]> Andrew Layman, Microsoft <[email protected]> Richard Tobin, University of Edinburgh and Markup Technology Ltd <[email protected]> Henry S. Thompson, University of Edinburgh and W3C <[email protected]> Please refer to the errata See also translations This document is also available in these non-normative formats: XML HTML highlighting differences from the second edition Copyright W3C ® MIT ERCIM Keio liability trademark document use 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. This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index This document is a product of the XML Core Working Group W3C XML Activity 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) XML Test Suite This third edition incorporates all known errata as of the publication date. It supersedes the previous edition of 16 August 2006 This edition has been widely reviewed. Only minor editorial changes have been made since the 6 August 2009 Proposed Edited Recommendation. Please report errors in this document to [email protected] archives http://www.w3.org/XML/2009/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 Essential Claim(s) section 6 of the W3C Patent Policy 1 Motivation and Summary A Note on Notation and Usage XML Namespaces Basic Concepts Use of

URIs as Namespace Names Comparing

URI References Declaring Namespaces Qualified Names Using Qualified Names Applying Namespaces to Elements and Attributes Namespace Scoping Namespace Defaulting Uniqueness of Attributes Conformance of Documents Conformance of Processors A Normative References Other references The Internal Structure of XML Namespaces Changes since version 1.0 Acknowledgements Orphaned Productions 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 These considerations require that document constructs should have names constructed so as to avoid clashes between names from different markup vocabularies. This specification describes a mechanism, XML namespaces expanded names Where EMPHASIZED MUST MUST NOT REQUIRED SHOULD SHOULD NOT MAY [Keywords] Note that many of the nonterminals in the productions in this specification are defined not here but in the XML specification [XML] In this document's productions, the NSC MUST [ Definition XML namespace [RFC3986] [ Definition expanded name namespace name local name Definition N I namespace name I N namespace name Definition local name N 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 Definition qualified name prefixed names unprefixed names MUST 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. Note: This deprecation of relative URI references was decided on by a W3C XML Plenary Ballot [Relative URI deprecation] URI references identifying namespaces are compared when determining whether a name belongs to a given namespace, and whether two names belong to the same namespace. [ Definition identical 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 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 URI 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. [ Definition (or more precisely, a namespace binding) declared xmlns begin xmlns: default NSAttName ::= PrefixedAttName | DefaultAttName PrefixedAttName ::= 'xmlns:' NCName [NSC: Reserved Prefixes and Namespace Names] DefaultAttName ::= 'xmlns' NCName ::= Name Char Char /* An XML Name The attribute's normalized value MUST namespace name SHOULD [RFC2141] [ Definition PrefixedAttName NCName namespace prefix namespace name [ Definition DefaultAttName namespace name default namespace 6 Applying Namespaces to Elements and Attributes An example namespace declaration, which associates the namespace prefix edi 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 http://www.w3.org/XML/1998/namespace MAY MUST NOT MUST NOT MUST NOT The prefix xmlns http://www.w3.org/2000/xmlns/ MUST NOT MUST NOT MUST NOT MUST NOT 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 processors MUST NOT 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. In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name MUST qualified names QName ::= PrefixedName | UnprefixedName PrefixedName ::= Prefix LocalPart UnprefixedName ::= LocalPart Prefix ::= NCName LocalPart ::= NCName The Prefix namespace prefix MUST namespace declaration Definition LocalPart local part Note that the prefix functions only SHOULD In XML documents conforming to this specification, element names qualified names STag ::= '<' QName S Attribute S [NSC: Prefix Declared] ETag ::= '</' QName S [NSC: Prefix Declared] 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> Attributes are either namespace declarations qualified names Attribute ::= NSAttName Eq AttValue | QName Eq AttValue [NSC: Prefix Declared] [NSC: No Prefix Undeclaring] [NSC: Attributes Unique] 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> Namespace constraint: Prefix Declared The namespace prefix, unless it is xml xmlns MUST namespace declaration content Namespace constraint: No Prefix Undeclaring In a namespace declaration prefix NSAttName PrefixedAttName attribute value MUST NOT This constraint may lead to operational difficulties in the case where the namespace declaration attribute is provided, not directly in the XML document entity If correct operation with such applications is required MUST internal subset of the DTD Element names and attribute names DTD doctypedecl ::= '<!DOCTYPE' S QName S ExternalID S markupdecl PEReference S S elementdecl ::= '<!ELEMENT' S QName S contentspec S cp ::= ( QName choice seq Mixed ::= '(' S S S QName S | '(' S S AttlistDecl ::= '<!ATTLIST' S QName AttDef S 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 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. The expanded name prefix namespace name local part local name <?xml version="1.0"?>

<html:html xmlns:html=' http://www.w3.org/1999/xhtml 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> The scope of a default namespace 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 default namespace namespace name local name local part <?xml version="1.0"?> <!-- elements are in the HTML namespace, in this case by default --> <html xmlns=' http://www.w3.org/1999/xhtml <?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 The attribute value in a default namespace declaration MAY <?xml version='1.0'?> <Beers> <!-- the default namespace inside tables is that of HTML http://www.w3.org/1999/xhtml Namespace constraint: Attributes Unique In XML documents conforming to this specification, no tag may contain two attributes which: have identical names, or have qualified names with the same local part prefixes namespace names identical This constraint is equivalent to requiring that no element have two attributes with the same expanded name For example, each of the bad <!-- 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> This specification applies to XML 1.0 documents. To conform to this specification, a document MUST [XML] In XML documents which conform to this specification, element and attribute names MUST QName MUST REQUIRED Name MUST NCName [ Definition namespace-well-formed 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. [ Definition namespace-valid REQUIRED Name NCName It follows that in a namespace-valid document: No attributes with a declared type of ID IDREF(S) ENTITY(IES) NOTATION To conform to this specification, a processor MUST REQUIRED [RFC3986] [ Definition namespace-validating RFC 2119: Key words for use in RFCs to Indicate Requirement Levels RFC 2141: URN Syntax Available at http://www.rfc-editor.org/rfc/rfc2141.txt. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 3629: UTF-8, a transformation format of ISO 10646 Extensible Markup Language (XML) 1.0 Namespaces in XML Errata Namespaces in XML (Second Edition) Errata Results of W3C XML Plenary Ballot on relative URI References In namespace declarations 3-17 July 2000 This appendix has been deleted. This version incorporates the errata as of 20 July 2009 [1.0 Errata] [1.0 2e Errata] 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. The BNF has been adjusted to interconnect properly with all editions of XML 1.0, including the fifth edition. 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. The following two productions are modified versions of ones which were present in the first two editions of this specification. They are no longer used, but are retained here to satisfy cross-references to undated versions of this specification. Because the Letter NCNameStartChar NCNameStartChar NCNameStartChar NCName NCNameChar ::= NameChar /* An XML NameChar NCNameStartChar ::= NCName Char Char Char /* The first letter of an NCName Note: Production NC-NCNameStartChar

Related documents

Record · ID 153268 · SHA-256 b4a649e5fdab9852
Conceptio Open Knowledge Archive — every document is proof-bundled with source, license, and retrieval metadata.