Namespaces in XML 1.1

W3C Working Draft 5 September 2002

This version:
Latest version:
Previous version:
Tim Bray, Textuality <tbray@textuality.com>
Dave Hollander, Contivo, Inc. <dmh@contivo.com>
Andrew Layman, Microsoft <andrewl@microsoft.com>
Richard Tobin, University of Edinburgh and Markup Technology Ltd <richard@cogsci.ed.ac.uk> - Version 1.1

This document is also available in these non-normative formats: XML and HTML with differences highlighted.


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 IRI references.

Status of this Document

The XML Core Working Group, with this Namespaces in XML 1.1 Last Call working draft, invites comment on this specification. The Last Call period begins 5 September 2002 and ends 28 September 2002.

This document is a draft of a new 1.1 revision of the Namespaces in XML specification. It incorporates several errata to the 1.0 specification, and one substantive change: the provision of a mechanism to "undeclare" prefixes. Since documents using this new feature will not work with existing processors, this revision is being tied to the 1.1 revision of XML itself. XML 1.0 documents must continue to use version 1.0 of this specification. There is a requirements document for this revision [Requirements].

This is a W3C Working Draft for review by W3C Members and other interested parties. It has been produced as part of the XML Activity. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

Patent disclosures relevant to this specification may be found on the Working Group's public patent disclosure page.

This is work in progress and does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR.

Comments and discussion on this document should be sent to xml-names-editor@w3.org (public archive).

The final version of this specification will refer to terms and productions from the 1.1 revision of the XML specification. Since that specification does not yet exist in a suitable form, in this draft they are links to the 1.0 specification where the difference is unimportant, or links to placeholders within this draft.

Table of Contents

1 Motivation and Summary
    1.1 A Note on Notation and Usage
2 Declaring Namespaces
3 Qualified Names
4 Using Qualified Names
5 Applying Namespaces to Elements and Attributes
    5.1 Namespace Scoping
    5.2 Namespace Defaulting
    5.3 Uniqueness of Attributes
6 Conformance of Documents
7 Internationalized Resource Identifiers (IRIs)
8 XML 1.1 Productions


A References
B The Internal Structure of XML Namespaces (Non-Normative)
    B.1 The Insufficiency of the Traditional Namespace
    B.2 XML Namespace Partitions
    B.3 Expanded Element Types and Attribute Names
    B.4 Unique Expanded Attribute Names
C Acknowledgements (Non-Normative)

1 Motivation and Summary

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 tags 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 type or attribute name.

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.

[Definition: An XML namespace is a collection of names, identified by an IRI reference, which are used in XML documents as element types and attribute names. ] XML namespaces differ from the "namespaces" conventionally used in computing disciplines in that the XML version has internal structure and is not, mathematically speaking, a set. These issues are discussed in B The Internal Structure of XML Namespaces.

[Definition: IRI references which identify namespaces are considered identical if and only if they are exactly the same character-for-character.] Case differences and escaping differences (including case differences in escape sequences) are therefore significant. Note that IRI references which are not identical in this sense may in fact be functionally equivalent. Examples include IRI references which differ only in case or escaping , or which are in external entities which have different effective base URIs.

The empty string, though it is a legal IRI reference, cannot be used as a namespace name.

The use of relative IRI references, including same-document references, in namespace declarations is deprecated. Future W3C specifications will define no interpretation for them.

Names from XML namespaces may appear as qualified names, which may contain a single colon separating the name into a namespace prefix and a local part. The prefix, which is mapped to an IRI reference, selects a namespace. The combination of the universally managed IRI namespace and the document's own namespace produces identifiers that are universally unique. Mechanisms are provided for prefix scoping and defaulting.

IRI references can contain characters not allowed in names, so cannot be used directly as namespace prefixes. Therefore, the namespace prefix serves as a proxy for an IRI reference. An attribute-based syntax described below is used to declare the association of the namespace prefix with an IRI reference; software which supports this namespace proposal must recognize and act on these declarations and prefixes.

1.1 A Note on Notation and Usage

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.

Note that all Internet domain names used in examples, with the exception of w3.org, are selected at random and should not be taken as having any import.

2 Declaring Namespaces

[Definition: A namespace is declared using a family of reserved attributes. Such an attribute's name must either be xmlns or have xmlns: as a prefix. These attributes, like any other XML attributes, may be provided directly or by default. ]

Attribute Names for Namespace Declaration
[1]   NSAttName   ::=   PrefixedAttName
| DefaultAttName
[2]   PrefixedAttName   ::=   'xmlns:' NCName[NSC: Reserved Prefixes and Namespace Names]
[3]   DefaultAttName   ::=   'xmlns'
[4]   NCName   ::=   NCNameStartChar NCNameChar*/* An XML Name, minus the ":" */
[5]   NCNameChar   ::=   NameChar - ':'
[5a]   NCNameStartChar   ::=   NameStartChar - ':'

[Definition: The attribute's value, an IRI reference, is the namespace name identifying the 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 [RFC2141]. 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.] The attribute value may be an empty string.

[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.] The attribute value may be an empty string. Default namespaces and overriding of declarations are discussed in 5 Applying Namespaces to Elements and Attributes.

An example namespace declaration, which associates the namespace prefix edi with the namespace name http://ecommerce.org/schema:

<x xmlns:edi='http://ecommerce.org/schema'>
  <!-- the "edi" prefix is bound to http://ecommerce.org/schema
       for the "x" element and contents -->

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. No other prefix may be bound to this namespace name.

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. No other prefix may be bound to this namespace name.

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, as these names would be reserved if used without a prefix.

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
[6]   QName   ::=    (Prefix ':')? LocalPart
[7]   Prefix   ::=   NCName
[8]   LocalPart   ::=   NCName

The Prefix provides the namespace prefix part of the qualified name, and must be associated with a namespace IRI 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.

4 Using Qualified Names

In XML documents conforming to this specification, element types are given as qualified names, as follows:

Element Types
[9]   STag   ::=   '<' QName (S Attribute)* S? '>' [NSC: Prefix Declared]
[10]   ETag   ::=   '</' QName S? '>'[NSC: Prefix Declared]
[11]   EmptyElemTag   ::=   '<' QName (S Attribute)* S? '/>'[NSC: Prefix Declared]

An example of a qualified name serving as an element type:

<x xmlns:edi='http://ecommerce.org/schema'>
  <!-- the 'price' element's namespace is http://ecommerce.org/schema -->
  <edi:price units='Euro'>32.18</edi:price>

Attributes are either namespace declarations or their names are given as qualified names:

[12]   Attribute   ::=   NSAttName Eq AttValue
| QName Eq AttValue[NSC: Prefix Declared]

An example of a qualified name serving as an attribute name:

<x xmlns:edi='http://ecommerce.org/schema'>
  <!-- the 'taxClass' attribute's namespace is http://ecommerce.org/schema -->
  <lineItem edi:taxClass="exempt">Baby food</lineItem>

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). Furthermore, the attribute value in the innermost such declaration 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. For correct operation with such applications, namespace declarations must be provided either directly or via default attributes declared in the internal subset of the DTD.

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

Qualified Names in Declarations
[13]   doctypedecl   ::=   '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>'
[14]   elementdecl   ::=   '<!ELEMENT' S QName S contentspec S? '>'
[15]   cp   ::=   (QName | choice | seq) ('?' | '*' | '+')?
[16]   Mixed   ::=   '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[17]   AttlistDecl   ::=   '<!ATTLIST' S QName AttDef* S? '>'
[18]   AttDef   ::=   S (QName | NSAttName) S AttType S DefaultDecl

5 Applying Namespaces to Elements and Attributes

5.1 Namespace Scoping

A namespace declaration is considered to apply to the element where it is specified and its attributes, and to all elements and their attributes within the content of that element, unless overridden by another namespace declaration with the same NSAttName part:

<?xml version="1.1"?>

<!-- all elements here are explicitly in the HTML namespace -->
<html:html xmlns:html='http://www.w3.org/TR/REC-html40'>
  <html:body><html:p>Moved to 
    <html:a href='http://frob.com'>here.</html:a></html:p></html:body>

Multiple namespace prefixes can be declared as attributes of a single element, as shown in this example:

<?xml version="1.1"?>
<!-- both namespace prefixes are available throughout -->
<bk:book xmlns:bk='urn:loc.gov:books'
    <bk:title>Cheaper by the Dozen</bk:title>

The attribute value in a namespace declaration for a prefix may be empty. This has the effect, within the scope of the declaration, of removing any association of the prefix with a namespace name. Further declarations may re-declare the prefix again:

<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
    <n1:a/>               <!-- legal; the prefix n1 is bound to http://www.w3.org -->
    <x xmlns:n1="">
        <n1:a/>           <!-- illegal; the prefix n1 is not bound here -->
	<x xmlns:n1="http://www.w3.org">
            <n1:a/>       <!-- legal; the prefix n1 is bound again -->

5.2 Namespace Defaulting

A default namespace declaration is considered to apply to the element where it is specified, and to all elements within the content of that element, unless overridden by another default namespace declaration. If the IRI reference in a default namespace declaration is empty, then unprefixed elements in the scope of the declaration are not considered to be in any namespace. Note that default namespaces do not apply directly to attributes.

<?xml version="1.1"?>
<!-- elements are in the HTML namespace, in this case by default -->
<html xmlns='http://www.w3.org/TR/REC-html40'>
  <body><p>Moved to 
    <a href='http://frob.com'>here</a>.</p></body>
<?xml version="1.1"?>
<!-- unprefixed element types are from "books" -->
<book xmlns='urn:loc.gov:books'
    <title>Cheaper by the Dozen</title>

A larger example of namespace scoping:

<?xml version="1.1"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
    <title>Cheaper by the Dozen</title>
      <!-- make HTML the default namespace for some commentary -->
      <p xmlns='urn:w3-org-ns:HTML'>
          This is a <i>funny</i> book!

The default namespace can be set to the empty string. This has the same effect, within the scope of the declaration, of there being no default namespace.

<?xml version='1.1'?>
  <!-- the default namespace is now that of HTML -->
  <table xmlns='http://www.w3.org/TR/REC-html40'>
     <!-- no default namespace inside table cells -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origin xmlns="">Bath, UK</origin></td>
       <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
         <pro>Wonderful hop, light alcohol, good summer beer</pro>
         <con>Fragile; excessive variance pub to pub</con>

5.3 Uniqueness of Attributes

In XML documents conforming to this specification, no tag may contain two attributes which:

  1. have identical names, or

  2. have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.

For example, each of the bad start-tags is illegal in the following:

<!-- 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" />

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

6 Conformance of Documents

This specification applies to XML 1.1 documents. To conform to this specification, a document must be well-formed according to the XML 1.1 specification.

In XML documents which conform to this specification, element types 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.1 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:

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.1 specification, and all tokens other than element types and attribute names which are required, for XML 1.1 validity, to match the XML production for Name, match this specification's production for NCName. ]

It follows that in a namespace-valid document:

7 Internationalized Resource Identifiers (IRIs)

Some characters are disallowed in URI references, even if they are allowed in XML; the disallowed characters, according to [RFC2396] and [RFC2732], are the control characters #x0 to #x1F and #x7F, space #x20, the delimiters '<' #x3C, '>' #x3E and '"' #x22, the unwise characters '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E and '`' #x60, as well as all characters above #x7F.

[Definition: An IRI reference is a string that can be converted to a URI reference by escaping all disallowed characters as follows: ]

  1. Each disallowed character is converted to UTF-8 [Unicode 3.2] as one or more bytes.

  2. The resulting bytes are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).

  3. The original character is replaced by the resulting character sequence.

8 XML 1.1 Productions

This section will not be present in the final version of this specification. It contains productions that will appear in the XML 1.1 specification and are different from those in XML 1.0.

XML 1.1 Productions
[19]   Name   ::=   NameStartChar NameChar*
[20]   NameChar   ::=   /* To be defined in XML 1.1 */
[21]   NameStartChar   ::=   /* To be defined in XML 1.1 */

A References

Namespaces in XML 1.1 Requirements, ed. Jonathan Marsh. March 2002. Available at http://www.w3.org/TR/2002/WD-xml-names11-req-20020403
IETF (Internet Engineering Task Force) RFC 2141: URN Syntax, ed. R. Moats. May 1997. Available at ftp://ftp.ietf.org/rfc/rfc2141.txt
IETF (Internet Engineering Task Force) RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, eds. T. Berners-Lee, R. Fielding, L. Masinter. August 1998. Available at ftp://ftp.ietf.org/rfc/rfc2396.txt
IETF (Internet Engineering Task Force) RFC 2732: Format for Literal IPv6 Addresses in URL's, eds. R. Hinden, B. Carpenter, L. Masinter. December 1999. Available at http://www.ietf.org/rfc/rfc2732.txt
Unicode 3.2
The Unicode Consortium The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (see http://www.unicode.org/reports/tr27) and by the Unicode Standard Annex #28: Unicode 3.2 ( http://www.unicode.org/reports/tr28).
Extensible Markup Language (XML) 1.0 (Second Edition), eds. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, and Eve Maler. 6 October 2000. Available at http://www.w3.org/TR/2000/REC-xml-20001006.

B The Internal Structure of XML Namespaces (Non-Normative)

B.1 The Insufficiency of the Traditional Namespace

In the computing disciplines, the term "namespace" conventionally refers to a set of names, i.e. a collection containing no duplicates. However, treating the names used in XML markup as such a namespace would greatly impair their usefulness. The primary use of such names in XML documents is to enable identification of logical structures in documents by software modules such as query processors, stylesheet-driven rendering engines, and schema-driven validators. Consider the following example:

<section><title>Book-Signing Event</title>
  <author title="Mr" name="Vikram Seth" />
  <book title="A Suitable Boy" price="$22.95" /></signing>
  <author title="Dr" name="Oliver Sacks" />
  <book title="The Island of the Color-Blind" price="$12.95" /></signing>

In this example, there are three occurrences of the name title within markup, and the name alone clearly provides insufficient information to allow correct processing by a software module.

Another problematic area comes from the use of "global" attributes, as illustrated by this example, a fragment of an XML document which is to be displayed using a CSS stylesheet:

 <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
 <SEAT CLASS="Y" HTML:CLASS="reallyImportant">33B</SEAT>

In this case, the CLASS attribute, which describes the fare basis and takes values such as "J", "Y", and "C", is distinct at all semantic levels from the HTML:CLASS attribute, which is used to simulate syntactic richness in HTML, as a means of overcoming the limited element repertoire by subclassing.

XML does not provide a built-in way to declare "global" attributes; items such as the HTML CLASS attribute are global only in their prose description and their interpretation by HTML applications. However, such attributes, an important distinguishing feature of which is that their names are unique, are commonly observed to occur in a variety of applications.

B.2 XML Namespace Partitions

In order to support the goal of making both qualified and unqualified names useful in meeting their intended purpose, we identify the names appearing in an XML namespace as belonging to one of several disjoint traditional (i.e. set-structured) namespaces, called namespace partitions. The partitions are:

The All Element Types Partition

All element types in an XML namespace appear in this partition. Each has a unique local part; the combination of the namespace name and the local part uniquely identifies the element type.

The Global Attribute Partition

This partition contains the names of all attributes which are defined, in this namespace, to be global. The only required characteristic of a global attribute is that its name be unique in the global attribute partition. This specification makes no assertions as to the proper usage of such attributes. The combination of the namespace name and the attribute name uniquely identifies the global attribute.

The Per-Element-Type Partitions

Each type in the All Element Types Partition has an associated namespace in which appear the names of the unqualified attributes that are provided for that element. This is a traditional namespace because the appearance of duplicate attribute names on an element is forbidden by XML. The combination of the attribute name with the element's type and namespace name uniquely identifies each unqualified attribute.

In XML documents conforming to this specification, the names of all qualified (prefixed) attributes are assigned to the global attribute partition, and the names of all unqualified attributes are assigned to the appropriate per-element-type partition.

B.3 Expanded Element Types and Attribute Names

For convenience in specifying rules and in making comparisons, we define an expanded form, expressed here in XML element syntax, for each element type and attribute name in an XML document.

[Definition: An expanded element type is expressed as an empty XML element of type ExpEType. It has a required type attribute which gives the type's LocalPart, and an optional ns attribute which, if the element is qualified, gives its namespace name.]

[Definition: An expanded attribute name is expressed as an empty XML element of type ExpAName. It has a required name attribute which gives the name. If the attribute is global, it has a required ns attribute which gives the namespace name; otherwise, it has a required attribute eltype which gives the type of the attached element, and an optional attribute elns which gives the namespace name, if known, of the attached element.]

Slight variations on the examples given above will illustrate the working of expanded element types and attribute names. The following two fragments are each followed by a table showing the expansion of the names:

<!-- 1 --> <section xmlns='urn:com:books-r-us'>
<!-- 2 -->   <title>Book-Signing Event</title>
<!-- 3 -->   <signing>
<!-- 4 -->     <author title="Mr" name="Vikram Seth" />
<!-- 5 -->     <book title="A Suitable Boy" price="$22.95" />

The names would expand as follows:

1section<ExpEType type="section" ns="urn:com:books-r-us" />
2title<ExpEType type="title" ns="urn:com:books-r-us" />
3signing<ExpEType type="signing" ns="urn:com:books-r-us" />
4author<ExpEType type="author" ns="urn:com:books-r-us" />
4title<ExpAName name='title' eltype="author" elns="urn:com:books-r-us" />
4name<ExpAName name='name' eltype="author" elns="urn:com:books-r-us" />
5book<ExpEType type="book" ns="urn:com:books-r-us" />
5title<ExpAName name='title' eltype="book" elns="urn:com:books-r-us" />
5price<ExpAName name='price' eltype="book" elns="urn:com:books-r-us" />
<!-- 1 --> <RESERVATION xmlns:HTML="http://www.w3.org/TR/REC-html40">
<!-- 2 --> <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
<!-- 3 --> <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT>
<!-- 4 --> <HTML:A HREF='/cgi-bin/ResStatus'>Check Status</HTML:A>
<!-- 5 --> <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>
2NAME<ExpEType type="NAME" />
2HTML:CLASS<ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" />
3SEAT<ExpEType type="SEAT" />
3CLASS<ExpAName name="CLASS" eltype="SEAT" />
3HTML:CLASS<ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" />
4HTML:A<ExpEType type="A" ns="http://www.w3.org/TR/REC-html40" />
4HREF<ExpAName name="HREF" eltype="A" elns="http://www.w3.org/TR/REC-html40" />

B.4 Unique Expanded Attribute Names

The constraint expressed by 5.3 Uniqueness of Attributes above may straightforwardly be implemented by requiring that no element have two attributes whose expanded names are equivalent, i.e. have the same attribute-value pairs.

C Acknowledgements (Non-Normative)

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. The contributions of Charles Frankston of Microsoft were particularly valuable.