Please refer to the errata for this document, which may include normative corrections.
See also translations.
This document is also available in these non-normative formats: XML and HTML highlighting differences from the second edition.
Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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 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 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_ADDRESS>public archives are available. The errata list for this document is available at 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 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
1.1
A Note on Notation and Usage
2 XML Namespaces
2.1 Basic Concepts
2.2
Use of URIs as Namespace Names
2.3
Comparing URI References
3 Declaring Namespaces
4 Qualified Names
5 Using Qualified Names
6
Applying Namespaces to Elements and Attributes
6.1 Namespace Scoping
6.2
Namespace Defaulting
6.3
Uniqueness of Attributes
7 Conformance of Documents
8 Conformance of Processors
A Normative References
B Other references (Non-Normative)
C
The Internal Structure of XML Namespaces
(Non-Normative)
D Changes since version 1.0 (Non-Normative)
E Acknowledgements (Non-Normative)
F Orphaned Productions (Non-Normative)
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.
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, which accomplishes this by assigning expanded names to elements and attributes.
Where EMPHASIZED, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY in this document are to be interpreted as described in [Keywords].
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.
[Definition: An XML namespace is identified by a URI reference [RFC3986]; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]
[Definition: An expanded name is a pair consisting of a namespace name and a local name. ] [Definition: For a name N in a namespace identified by a URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value. ] [Definition: In either case the local name is N. ] It is this combination of the universally managed URI 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. [Definition: A qualified name is a name subject to namespace interpretation. ] In documents conforming to this specification, element and attribute names appear as qualified names. Syntactically, they are either prefixed names or unprefixed names. An attribute-based declaration syntax is provided to bind prefixes to namespace names and to bind a default namespace that applies to unprefixed element names; these declarations are scoped by the elements on which they appear so that different bindings may apply in different parts of a document. Processors conforming to this specification MUST recognize and act on these declarations and prefixes.
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]. It also declares that "later specifications such as DOM, XPath, etc. will define no interpretation for them".
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: 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 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: A namespace (or more precisely, a namespace binding) is declared using a family of reserved attributes. Such an attribute's name must either be xmlns or begin xmlns:. These attributes, like any other XML attributes, may be provided directly or by default. ]
| [1] | NSAttName |
::= |
PrefixedAttName
|
|
| DefaultAttName
|
||||
| [2] | PrefixedAttName |
::= |
'xmlns:' NCName
|
[NSC: Reserved Prefixes and Namespace Names] |
| [3] | DefaultAttName |
::= | 'xmlns' |
|
| [4] | NCName |
::= |
Name -
(Char* ':'
Char*)
|
/* An XML Name, minus the ":" */ |
The attribute's normalized value MUST be either a URI reference — the namespace name identifying the namespace — or an empty string. The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). Uniform Resource Names [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.
[Definition: If the attribute name matches PrefixedAttName, then the NCName gives the namespace prefix, used to associate element and attribute names with the namespace name in the attribute value in the scope of the element to which the declaration is attached. ]
[Definition: If the attribute name matches DefaultAttName, then the namespace name in the attribute value is that of the default namespace in the scope of the element to which the declaration is attached.] Default namespaces and overriding of declarations are discussed in 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'>  </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.
In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name) MUST be given as qualified names, defined as follows:
| [7] | QName |
::= |
PrefixedName
|
| UnprefixedName
|
|||
| [8] | PrefixedName |
::= |
Prefix ':'
LocalPart
|
| [9] | UnprefixedName |
::= |
LocalPart
|
| [10] | Prefix |
::= |
NCName
|
| [11] | LocalPart |
::= |
NCName
|
The Prefix provides the namespace prefix part of the qualified name, and MUST be associated with a namespace URI reference in a namespace declaration. [Definition: The 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.
In XML documents conforming to this specification, element names are given as qualified names, as follows:
| [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:
 <edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>
Attributes are either namespace declarations or their names are given as qualified names:
| [15] | 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'>  <lineItem edi:taxClass="exempt">Baby food</lineItem> </x>
Namespace constraint: Prefix Declared
The namespace prefix, unless it is xml
or
xmlns
,
MUST
have been declared in a
namespace declaration
attribute in either the start-tag of the element where the prefix is
used or in an ancestor element (i.e., an element in whose
content the
prefixed markup occurs).
Namespace constraint: No Prefix Undeclaring
In a namespace declaration for a prefix (i.e., where the NSAttName is a PrefixedAttName), the attribute value MUST NOT be empty.
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:
| [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.
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.

The expanded name corresponding to a prefixed element or attribute name has the URI to which the prefix is bound as its namespace name, and the local part as its local name.
<?xml version="1.0"?>

Frobnostication
Moved to
here.

Multiple namespace prefixes can be declared as attributes of a single element, as shown in this example:
<?xml version="1.0"?>  <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 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"?>

<title>Frobnostication</title>

Moved to
here.

<?xml version="1.0"?>  <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"?>

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

This is a funny book!

</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>
 Name	Origin	Description
  <brandName xmlns="">Huntsman</brandName>	 <origin xmlns="">Bath, UK</origin>	  <class>Bitter</class><hop>Fuggles</hop> <pro>Wonderful hop, light alcohol, good summer beer</pro> <con>Fragile; excessive variance pub to pub</con>

 </Beers>
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 and with prefixes which have been bound to namespace names that are identical.
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:
 <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:
 <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 be well-formed according to the XML 1.0 specification [XML].
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.
[Definition: A namespace-well-formed document is namespace-valid if it is valid according to the XML 1.0 specification, and all tokens other than element and attribute names which are REQUIRED, for XML 1.0 validity, to match the XML production for Name match this specification's production for 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.
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 URI references [RFC3986].
[Definition: A validating XML processor that conforms to this specification is namespace-validating if in addition it reports violations of namespace validity. ]
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
production of XML 1.0, originally used
in the definition of NCNameStartChar
, is no longer the
correct basis for defining names since XML 1.0 Fifth Edition, the
NCNameStartChar
production has been modified to give the
correct results against any edition of XML, by defining
NCNameStartChar
in terms of
NCName.
| [5] | NCNameChar |
::= |
NameChar
- ':'
/* An XML
NameChar, minus the ":" */
|
| [6] | NCNameStartChar |
::= |
NCName - (
Char
Char
Char* )
/* The first letter of an
NCName */
|
Note:
Production NC-NCNameStartChar takes advantage of the fact that a single-character NCName is necessarily an NCNameStartChar, and works by subtracting from the set of NCNames of all lengths the set of all strings of two or more characters, leaving only the NCNames which are one character long.


SortedContainers provides sorted container types, written in pure-Python and fast as C-extensions.
If you or your organization uses SortedContainers, consider financial support:
Give to Sorted Containers


Setup Instructions
This kit has been assembled to accomplish the streaming needs from remote sites without reliable Wifi connections. There are quite a few parts that must work together for this service to work.
This guide walks through the connection and setup to get a stream started.
If you have any questions about how things work, Please see the device instructions in the sidebar on the left.
Technology
Basic Components of the system:
- GoPro Hero 8 Camera
- Stabilization Gimbal
- Teradek streaming encoder
- Omnicharge Ultimate battery
- Extension poles for gimbal
- Backpack to hold it all together
For the full list see the documents in the camera bag.
Physical Assembly
Connecting everything.
Cabling and Connections
How to plug it together
Hardware
Go Pro Hero 8
Simple to use action camera for both recording video locally as well as streaming to the site.
The camera has a micro SD card installed that will allow up to 2.5 hours of video to be recorded. While streaming the camera does not need to be recording to stream.
While connected to the Teradek Encoder the rear touch screen is disabled and the front screen will show an external screen icon.
Clearing the Display
There are a few steps to clearing the on screen display from the video feed and must be done every startup.
- Connect the camera to power and video
- Power on the Encoder
- Power on the camera
- Press the Mode Button 2 times
- Press the Shutter Button 1 time
- Press the Mode Button 4 times
- Press the Shutter Button 1 time
The screen is now clear and ready to stream!
Recording while Streaming
Once the screen is clear and the encoder is connected you can optionally record the video directly on the GoPro. This video then can be uploaded for later viewing. See the Uploading section FIXME
- With the camera powered on Press the Shutter button to begin recording.
- Press again to stop.
Audio is recorded with the video directly on the camera. Watch what you say while recording!
Downloading Videos
To remove the recordings from the camera and save them to a computer or HDD:
- Remove the SD Card from the camera
- Insert into a card reader
- Transfer files
- Reinstall SD card into camera
Teradek Vidiu Go
The Teradek Vidiu Pro is the component responsible for getting the video online. This device takes the video signal from the camera and encodes it into web traffic and sends it to our streaming server.
There is a lot going on here, however once setup it is as simple as pressing the stream button.
Basic Streaming
- Power on the encoder
- Wait for all of the network connections to establish. You must be connected for the system to function
- Browse to broadcast settings in the menu and select the correct stream destination
- With video connected press the red streaming button and confirm the selection
- Stream is live! Log into the correct page and view the feed
Web Interface
The Teradek Vidiu Go will serve up a configuration page if you are connected directly to the unit in AP mode, or if you are on the same internal LAN either wired or wireless.
Browse to the IP address shown on the unit when you press the down arrow.
Broadcast Settings
Select the stream to send video to in the Settings tab --> broadcast --> manage
and select one of the pre-stored stream destinations.
You will need to use the corresponding link to view the stream.
Network Settings
The Encoder can utilize multiple network connections to send the stream. Typically either WIFI (prefered) or Cellular will be used to transmit the video feed.
Wifi
Enter the network menu and configure the wifi to use a nearby network.
Cellular
NEED TO CONFIGURE THIS STILL!