A namespace is declared using a reserved processing instruction as follows: Namespace Declaration PI NamespacePI '<?xml:namespace' (S (PrefixDef | NSDef | SrcDef))+ '?>' NSDef 'ns' Eq SystemLiteral SrcDef 'src' Eq SystemLiteral PrefixDef 'prefix' Eq ("'" NCName "'" | '"' NCName '"') NCName (Letter | '_') (NCNameChar)*An XML Name, minus the ":" NCNameChar Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender The SystemLiteral in the NSDef production is a URI which functions as a namespace name to identify the namespace. The SystemLiteral in the SrcDef production is an optional URI which may be used to retrieve the schema, if one is provided. Some namespaces need no schemas; this specification does not depend on their existence, or on the use of any particular machine- or human-readable syntax in the schema.

The NCName in the PrefixDef production gives the namespace prefix used to associate names in an XML document with this namespace.

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). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names . However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals.

Examples of namespace declarations: ]]>

Namespace declarations must be located in the prolog of an XML document, after the XML Declaration (if any) and before the DTD (if any). This effectively makes the scope of namespace prefixes global to the whole document, including the DTD. It also means that should a processor wish to insert its own qualified names, it need only read the namespace declarations from the prolog to be sure of generating a new, unique, namespace prefix.

In XML documents conforming to this specification, the prolog must match the following production: Prolog with Namespace Declarations prolog XMLDecl? (NamespacePI | Misc)* (doctypedecl Misc*)? Note that the namespace declarations are ordinary processing instructions which the XML processor will pass to the application as it does any other.

In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name) may be given as qualified names, defined as follows: Qualified Name QName (Prefix ':')? LocalPart Prefix NCName LocalPart NCName The Prefix provides the namespace prefix part of the qualified name, and must be associated with defining schema through the URI in the applicable namespace declaration.

The LocalPart provides the local name part of the qualified name.

For each qualified name, there is a corresponding universal name, which is an ordered pair containing first, the namespace name associated with its prefix, and second, its local name.

A universal name is independent of the prefix in use in any particular XML document; thus, universal names provide a basis for comparing named objects located in different XML documents.

In XML documents conforming to this specification, element types are given as qualified names, as follows. In the productions below, the nonterminals (STag, ETag, EmptyElement, and Attribute) are taken from the XML specification ; the productions in all cases match a subset of the strings matched by those of the same name in the XML spec. Start-tag STag '<' QName (S Attribute)* S? '>' ETag '</' QName S? '>' EmptyElement '<' QName (S Attribute)* S? '/>'

Attribute names are given as qualified names, as follows: Attribute Attribute QName Eq AttValue An attribute whose name is not qualified, but which is attached to an element whose type is qualified, is in the namespace of the element type prefix. In the following example, the href is considered to come from the namespace associated with the prefix html. The W3C]]>

Processing instruction targets are given as qualified names, as follows: PI Target PITarget QName

When a schema is provided for a namespace, there is no guarantee that a universal name's combination of namespace name and local name will provide sufficient information to locate the appropriate description in the schema for the named object, if any exists. The XML document type definition is an example of a schema language in which this is possible. In a DTD, many attributes can be declared which share a name; they are distinguished by being attached to different element types.

This is not always a problem; consider one of the HTML 4.0 DTDs; these define two attributes, CLASS and STYLE, for use with stylesheets. This attribute is defined in such a way that it may apply to virtually every element, and that its semantics are identical wherever applied. Thus, given a namespace prefix html for which the corresponding schema is an HTML4 DTD, the following would present no problems: Sudden death may ensue.]]>

On the other hand, consider a document that wishes to use data types defined by ISO Standard 31, which deals with units of measure. In ISO 31, the unit "degrees" can apply to measures of several very different quantities. Thus, assuming the prefix ISO denotes a namespace associated with ISO 31, whatever the schema language in use, the following would almost certainly be ambiguous: ]]>

To make this more concrete, consider a schema which is an XML DTD containing the following declarations: ]]> Suppose that in some document this DTD is associated with a namespace identified by the prefix T. Then, in the following example, it is impossible (without extra external information) to distinguish whether T:Temp is the Temp attribute associated with the Heat element, or that associated with the Color element: ]]>

This problem can in general be addressed by using multiple namespaces. In the immediately preceding example, it would be necessary to declare namespaces with prefixes, for example, T.Heat and T.Color, whose associated namespace names would select the parts of the schema that described, respectively, the attributes of the Heat and Color attributes. Then the example could be disambiguated as follows: ]]>

Names in XML documents which conform to this specification are element types, attribute names and PI targets which match the production for QName.

An XML document conforms to this specification if all other tokens in the document which are required, for XML conformance, to match the XML production for Name, match this specification's production for NCName.

The effect of conformance is that in such a document:

All element types, attribute names and PI targets contain either zero or one colon.

Strictly speaking, attribute values declared to be of types ID, IDREF(S), ENTITY(IES), and NOTATION are also Names, thus should be colon-free. However, the declared type of attribute values is in principle only available in documents which have been validated. Thus, in well-formed XML documents, there can be no assurance that the contents of attribute values have been checked for conformance to this specification.

Imagine an XML document representing an invoice for books. If public schemas exist for elements and attributes describing books, electronic transactions and digital signatures, the invoice author should be able to use these, rather than inventing new element and attribute types. Any reader of the invoice document should be able to infer a consistent meaning to its contents, the same meaning as if the elements and attributes had appeared in a different kind of document (such as an invoice for automotive parts, or an inventory of books or a digital signature on a legal contract). A search tool should be able to locate the elements, regardless of the document in which they reside. Further, since several schemas may choose the same name (e.g. "size") for elements or attributes with different meanings, these must be distinguished if used within the same document.