A namespace is declared using a reserved processing instruction as follows: Namespace Declaration PI NamespacePI '<?xml:namespace' S 'name=' SystemLiteral S 'href=' SystemLiteral S 'as=' NSName S? '?>' NSName ' Name ' | " Name " The "name" SystemLiteral is a URI which uniquely identifies the namespace. The "href" SystemLiteral 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 NSName gives the namespace name which will be used as a link to associate names in an XML document with this schema. 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 names 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 name.

To accomplish this, the production for prolog is replaced as follows: Prolog with Namespace Declarations prolog XMLDecl? S? NamespacePI* Misc* (doctypedecl Misc*)? Unique Namespace Names

No namespace name may be declared more than once.

Within the document, some names (constructs corresponding to the nonterminal Name) are replaced by qualified names, defined as follows: Qualified Name QName (NSPart ':')? LocalPart NSPart Name LocalPart Name The NSPart provides the namespace name part of the qualified name, and may be associated with defining schema through the URI in the applicable namespace declaration.

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

To enable the proper use of qualified names, it is necessary to banish colons from all Names which are not qualified; two productions are replaced as follows: Name Name (Letter | '_' ) (NameChar)* MiscName '.' | '-' | '_' | CombiningChar | Ignorable | Extender

Element types may be given as qualified names. To do this, the productions for start-, end-, and empty-element tags (STag, ETag, and EmptyElement) are replaced as follows: Start-tag STag '<' QName (S Attribute)* S? '>' ETag '</' QName S? '>' EmptyElement '<' QName (S Attribute)* S? '/>'

Attribute names are given as qualified names. To do this, the production for Attribute is replaced as follows: Attribute Attribute QName Eq AttValue

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). Any search tool should 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.

The XML specification uses Name in the following contexts:

PI target

Existing SGML practice shows that attributes are often used for much the same purposes as elements, with the choice determined by evolutionary history and design aesthetics as often as by differences in element and attribute capabilities. Also, certain kinds of attributes are used on a wide range of element types (for example, those employed in XML Links, those that might indicate the datatype of an element, etc.). Thus, attribute names are a strong candidate for qualification.

Furthermore, on the basis of consistency and simplicity, it might be argued that if one instance of Name is to be qualified, all should be.

On the other hand, attributes are already qualified by element types; that is, permissible values, defaults, and semantics of attributes depend on element types. It has been argued that further qualification of attributes by namespaces is unnecessary, and is even harmful for validation (see 4.2). Those attributes (e.g., xml:lang) which apply to all element types should rather be captured by a different mechanism (e.g.,#ALL in the WebSGML adaptation), as their permissible values, defaults, and semantics do not depend on element types.

Perhaps the most complicated issue surrounding namespaces is validation. In the discussion, many viewed validation as any process that verified document instance against a schema while others often referred to validation as "plain old DTD-wise validation with an XML processor, not any other kind of validation with an application". This white paper tries to support both schema validation and XML validation where XML validation is a special case of schema validation in which an XML processor uses a schema expressed in SGML DTD syntax. Furthermore, it tries to support XML validation with the minimum of change to existing XML processors, and to provide for qualified names for both element types and attribute names.

For generic schema validation it is anticipated that applications will validate against a set of semantics that are either predefined in an application standard or expressed in machine readable syntax. The system literal in the namespace declaration should be used to identify the specific schema and any associated data resources.

The two most commonly discussed approaches to XML validation were fragment merging and validation of a grove of independent fragments. These methods differ in how the the validation process is implemented, and should yield the same result. This specification most directly supports validation by fragment merging. Fragment merging validates the document instance against a DTD created by merging elements from the constituent DTD fragments. The merged-DTD may be created either by man or machine, on the fly or prior to validation. This approach has the advantage that once the merged-DTD is created, the validation process is unchanged from current SGML/XML practice.

XML validation using a grove of independent fragments involves decomposing a document into fragments, each of which can be validated with a component schema. Each fragment is a subtree such that every element in it comes from a single schema. The entire document is valid with respect to the entire schema exactly when each fragment is valid with respect to the component schema.  This approach has the advantage that the validation process uses unmodified DTDs. However, it was troubling to realize that supporting qualified attribute names precludes using a grove of independent fragments, due to the fact that attributes in each fragment could be from a different namespace and therefore must be validated against a different schema.

In considering the validation issues, it became apparent to many that we have not arrived at an consensus about what it means, in the general case, to apply an attribute from one schema to an element from another schema. Coupled with a growing concern about detailed meaning of multiple schema validation and a desire to develop an XML based syntax to express a superset of the SGML DTD semantics, it was decided to support the most straight forward XML validation technique that supported the requirements and which will also foster an environment where application developers can evolve working models of multiple namespace validation with various schema syntaxes.

Two mechanisms were discussed to associate between elements and namespace schemas; qualified names and a reserved attribute. While many in the discussion admired the simplicity of the reserved-attribute approach which required no namespace declaration and no new syntax, the qualified namespace prefix syntax was chosen because it supports two requirements not possible with URI attributes. In addition, namespace qualifiers may be more compact, more meaningful to a reader, easier to understand, describe and use than a reserved attribute.

Qualified names support the requirement to identify the schema for an attribute and to be able to apply an attribute from one document fragment to an element from another document fragment. The use of URI attributes would not allow an attribute from one namespace to be applied to an element from a different namespace fragment. Additionally, many believe qualifiers are needed for other names; id, idrefs, and enumerated attribute values and perhaps should be permitted on all names. This qualified name syntax will not need to change if we decide to support additional name types in the future.

This working draft does not specify how the URI system literal in the Namespace Declaration PI is to be used, aside from saying that it identifies the namespace schema. We anticipate that validating XML processors will use the QName for validation. Other applications are free to choose whether and how the URI,LocalPart pair are interpreted. Note: a future version of the namespace specification that addresses schema validation semantics may require the interpretation of the URI, LocalPart pair to be formalized.

A validating XML processor must be able to disambiguate between QNames that have the same LocalParts. One intent is to support the ability to merge two document fragments that have contain same generic identifier while still performing XML validation against the original content models. This ability to differentiate may also ease the deployment of stylesheets and the development other processing applications. Finally, because applications need only to control the NSPart prefix, qualified names simplify avoiding namespace collisions.

The syntax presented in this working draft uses a reserved processing instruction (PI) to associate a namespace qualifier with a network resource. In the discussions many alternatives were offered, including using a new declaration type, system notations or XLL links. While many considered PIs as the least desirable long term option, it was chosen for this draft because it is the most compatible with existing processing systems and should prove easy to migrate to another syntax in the future.

The ability to associate support multiple schemas with a name space qualifier was discussed. The multiple associations could provide both machine and human readable schemas or even multiple machine schemas. The namespace syntax in this working draft requires that there be exactly one namespace declaration PI for each namespace name. Future namespace specifications may establish conventions which support multiple associations as well as a mechanism to qualify a particular attribute of a specific element in a namespace.

The namespace syntax presented in this working draft severely constrains qualified names. The following constraints were chosen based on an understanding of the immediate requirements of other W3C actives and to reserve syntactical constructs to support extensions of the namespace mechanisms.

There is at most one colon per name. This working draft does not support the use of multiple colons to designate hierarchical namespaces, multiple inheritance or other semantics. It is anticipated that multi-part names will be discussed as mechanics to support implementing these features in a future version of the XML specification.

QNames use a single colon as a separator. The use of a double colon was discussed as a way to improve compatibility with the CSS specification even though most people preferred the single colon from a subjective and aesthetic perspective. After further investigation it was not shown that double colons would actually simplify the development of CSS compatible XML namespace aware applications. The single colon QName syntax used in this working draft is intended to support the use of CSS stylesheets in namespace aware XML applications.

The NSPart must not be empty. An empty NSPart could signal a processing semantic such as minimization. In this working draft, name parts must not be null for a document to be well formed. Future versions of the XML specification may establish the use empty QNames as a signal for namespace minimization.