W3CWD-xml-names-19980518


Namespaces in XML

World Wide Web Consortium Working Draft 18-May-1998

This version:
http://www.w3.org/TR/1998/WD-xml-names-19980518
Latest version:
http://www.w3.org/TR/WD-xml-names
Previous version:
http://www.w3.org/TR/1998/WD-xml-names-19980327
Editors:
Tim Bray (Textuality) <tbray@textuality.com>
Dave Hollander (Hewlett-Packard Company) <dmh@corp.hp.com>
Andrew Layman (Microsoft) <andrewl@microsoft.com>

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Status of this document

This draft specification is a work in progress representing the current consensus of the W3C XML Working Group. This is a W3C Working Draft for review by W3C members and other interested parties. Publication as a working draft does not imply endorsement by the W3C membership. While we do not anticipate substantial changes, we still caution that further changes are possible and therefore we recommend that only experimental software or software that can be easily field-upgraded be implemented to this specification at this time. The XML Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite W3C Working Drafts as other than "work in progress".

It is the intent of the XML Working Group that this namespace facility should become an integral part of some future version of the XML specification.

Abstract

XML namespaces provide a simple method for qualifying names used in Extensible Markup Language documents by associating them with namespaces identified by URI.

Table of Contents

1. Motivation and Summary
2. Namespace Syntax
    2.1 Declaring Namespaces
    2.2 Placing Declarations in Documents
    2.3 Qualified Names
    2.4 Using Qualified Names
    2.5 Ambiguity In Attributes
    2.6 Conformance
3. Examples
    3.1 The On-line Bookstore

Appendices

A. Acknowledgements
B. References

1. Motivation and Summary

We envision applications of Extensible Markup Language [XML] where a document contains markup defined in multiple schemas, which may have been authored independently. One motivation for this is that writing good schemas is hard, so it is beneficial to re-use parts from existing, well-designed schemas. Another is the advantage of allowing search engines or other tools to operate over a range of documents that vary in many respects but use common names for common element types.

These considerations require that document constructs should have universal names, whose scope extends beyond their containing document. This specification describes a mechanism, XML namespaces, which accomplishes this.

XML namespaces are based on the use of qualified names, which contain a single colon, separating the name into a namespace prefix and the local name. The prefix, which is mapped to a URI, selects a namespace. The combination of the universally managed URI namespace and the local name produces names that are guaranteed universally unique.

URIs can contain characters not allowed in names, so cannot be used directly as namespace prefixes. Therefore, the namespace prefix serves as a proxy for a URI. A special processing instruction described below is used to declare the association of the namespace prefix with a URI; software which supports this namespace proposal must recognize and act on it.

2. Namespace Syntax

2.1 Declaring Namespaces

[Definition:] A namespace is declared using a reserved processing instruction as follows:

Namespace Declaration PI
[1] NamespacePI ::= '<?xml:namespace' (S (PrefixDefNSDefSrcDef))+ '?>' [ NSC: Required Parts ]
[2] NSDef ::= 'ns' Eq SystemLiteral [ NSC: No Fragments ]
[3] SrcDef ::= 'src' Eq SystemLiteral
[4] PrefixDef ::= 'prefix' Eq ("'" NCName "'" | '"' NCName '"')
[5] NCName ::= (Letter | '_') (NCNameChar)* /* An XML Name, minus the ":" */
[6] NCNameChar ::= LetterDigit | '.' | '-' | '_' | CombiningCharExtender

[Definition:] 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.

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

Namespace Constraint: Required Parts
A namespace declaration must contain exactly one NSDef, exactly one PrefixDef and zero or one SrcDef.

Namespace Constraint: No Fragments
The SystemLiteral in the NSDef production must contain a URI, not including an attached #-separated fragment identifier.

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 [RFC2141]. 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:

<?xml:namespace ns='http://www.microsoft.com/' prefix='ms' ?>
<?xml:namespace ns='urn:ISBN:0-395-36341-6/' prefix='bk' ?>
<?xml:namespace ns='urn:uuid:C4ED1820-6207-11d1-A29F-00AA00C14882/'
                src='http://www.w3.org' prefix='w3c' ?>

2.2 Placing Declarations in Documents

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
[7] prolog ::= XMLDecl? (NamespacePI | Misc)* (doctypedecl Misc*)? [ NSC: Unique Prefix ]

Note that the namespace declarations are ordinary processing instructions which the XML processor will pass to the application as it does any other.

Namespace Constraint: Unique Prefix
A namespace prefix may not be declared more than once; i.e. there may not be two PrefixDefs which contain the same NCName string.

2.3 Qualified Names

[Definition:] 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
[8] QName ::= (Prefix ':')? LocalPart
[9] Prefix ::= NCName [ NSC: Prefix Declared ]
[10] LocalPart ::= NCName

The Prefix provides the namespace prefix part of the qualified name, and must be associated with a namespace URI in a namespace declaration. [Definition:] The LocalPart provides the local name part of the qualified name.

Note that the prefix functions only as a placeholder for a namespace name. Applications should use the namespace name and local name pair whenever a name is required whose scope extends beyond the containing document.

Namespace Constraint: Prefix Declared
The namespace prefix, unless it is "xml", must have been declared in a namespace declaration. The namespace prefix xml is reserved, and considered to have been implicitly declared. No other prefix beginning with the three-letter sequence x, m, l, in any case combination, is allowed.

2.4 Using Qualified Names

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 [XML]; the productions in all cases match a subset of the strings matched by those of the same name in the XML spec.

Element Types and Attribute Names
[11] STag ::= '<' QName (S Attribute)* S? '>'
[12] ETag ::= '</' QName S? '>'
[13] EmptyElement ::= '<' QName (S Attribute)* S? '/>'

Attribute names are given as qualified names, as follows:

Attribute
[14] 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. This specification does not provide a syntactic mechanism for determining whether the significance of, or definition for, the attribute is dependent on the element type to which it is attached; see "2.5 Ambiguity In Attributes".

Element names and attribute types are also given as qualified names when they appear in declarations in the DTD:

Qualified Names in Declarations
[15] doctypedecl ::= '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdeclPEReferenceS)* ']' S?)? '>'
[16] elementdecl ::= '<!ELEMENT' S QName S contentspec S? '>'
[17] cp ::= (QNamechoiceseq) ('?' | '*' | '+')?
[18] Mixed ::= '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[19] AttlistDecl ::= '<!ATTLIST' S QName AttDef* S? '>'
[20] AttDef ::= S QName S AttType S DefaultDecl

Processing instruction targets are given as qualified names, as follows:

PI Target
[21] PITarget ::= QName [ NSC: Declare Before Use ]

Namespace Constraint: Declare Before Use
When a PI target, aside from that in a namespace declaration PI, is qualified with a prefix, that prefix must be declared at a location in the document which precedes its use.

2.5 Ambiguity In Attributes

When a schema is provided for a namespace, there is no guarantee that the combination of namespace name and attribute name will provide sufficient information to locate the appropriate description in the schema (if any exists) for the attribute. 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 ambiguity is not always a problem. Consider one of the HTML 4.0 DTDs, which define two attributes, CLASS and STYLE, for use with stylesheets. The DTD and accompanying description define this attribute in such a way that it may apply to virtually every element, and that its semantics are identical wherever applied. Thus, given a prefix html which selects a namespace whose schema is that of HTML 4.0, the following would present no problems:

<Warning html:class='Important'>Sudden death may ensue.</Warning>

On the other hand, consider a document that uses 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:

<Item ISO:degrees='31'/>

To make this more concrete, consider a schema which is an XML DTD containing the following declarations:

<!ATTLIST Heat  Temp CDATA #IMPLIED>
<!ATTLIST Color Temp (3200|3400|5500) #IMPLIED>

Suppose that in some document this DTD is associated with a namespace identified by the prefix T. Then, in the following example, the syntax described in this specification does not provide sufficient information to distinguish whether T:Temp is the Temp attribute associated with the Heat element, or that associated with the Color element:

<Item T:Temp='3400'/>

In practical terms, it is expected that applications which process attributes will have built-in knowledge as to their meaning and the effect (if any) of their element context. Thus this should not be problem operationally. However, it 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, TempHeat and TempColor, 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:

<Item TempHeat:Temp='3400'/>

2.6 Conformance

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:

Strictly speaking, attribute values declared to be of types ID, IDREF(S), ENTITY(IES), and NOTATION are also Names, and 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.

3. Examples

3.1 The On-line Bookstore

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.

<?xml:namespace ns="http://books.org/schema/" prefix="B"?>
<?xml:namespace ns="http://ecommerce.org/schema/" prefix="E"?>
<?xml:namespace ns="http://digitalSignatures.org/schema/" prefix="dsig"?>
<?xml:namespace ns="urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882/" 
     prefix="dt"?>

<E:Order>
 <dsig:dsig>
   <E:Manifest>80183589575795589189518915</E:Manifest>
   <E:Sig href="http://XYX/Joe@company.com"/>
 </dsig:dsig>
 <E:SoldTo>
   <E:LastName>Layman</E:LastName>
   <E:FirstName>Andrew</E:FirstName>
 </E:SoldTo>

 <E:SoldOn dt:baseType="date.iso8601">1997-03-17</E:SoldOn>
 <E:Item Price="5.95">
   <B:BOOK TITLE="Number, the Language of Science" 
           AUTHOR="Dantzig, Tobias"/>
 </E:Item>
 <E:Item Price="12.95">
   <B:BOOK TITLE="Introduction to Objectivist Epistemology"
           AUTHOR="Rand, Ayn"/>
 </E:Item>
</E:Order>


Appendices

A. Acknowledgements

This work reflects input from a very large number of people, including especially the members of the World Wide Web Consortium XML Working Group and Special Interest Group, and the participants in the W3C Metadata Activity.

B. References

RFC2141
IETF (Internet Engineering Task Force) RFC 2141: URN Syntax, ed. R. Moats. May 1997.
XML
Extensible Markup Language (XML) 1.0, eds. Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen. 10 February 1998. Available at http://www.w3.org/TR/REC-xml.

Back/forward to the:
Last update: 28thJune,1998

Jochen M. Braun   (responsible for slight adaptions, not for the content of this document)
 (E-Mail: jbraun@astro.uni-bonn.de)