The names in a namespace form a collection:

The names in a namespace can, in theory at least, be defined to identify any thing or any number of things.

Given the wide variety of things that can be identified, it follows that an equally wide variety of ancillary resources may be relevant to a namespace. A namespace may have documentation (specifications, reference material, tutorials, etc., perhaps in several formats and several languages), schemas (in any of several forms), stylesheets, software libraries, applications, or any other kind of related resource.

A user, encountering a namespace might want to find any or all of these related resources. In the absence of any other information, a logical place to look for these resources, or information about them, is at the location of the namespace URI itself.

says that it is a Good Practice for the owner of a namespace to make available at the namespace URI “material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace”.

The question remains, how can we best provide both human and machine readable information at the namespace URI such that we can achieve the good practice identified by web architecture? One early attempt was . RDDL 1.0 is an XLink-based vocabulary for identifying the nature and purpose of related resources.

Several attempts were made to simplify RDDL. The TAG's original plan for addressing namespaceDocument-8 was to help define a simpler, standard RDDL format. However, this space has matured somewhat since the TAG's original discussions and RDDL 1.0 is now widely deployed. In addition, some of the proposed alternative formats are also deployed. And it seems likely that over time new variations may arise based on other evolving web standards.

This finding therefore attempts to address the problem by considering it in a more general fashion. We hope to:

For the resource identified by a namespace URI, there may exist other resources related to it. Borrowing on the terminology defined by , we say that each of these other resources has a nature and a purpose. The nature of the resource is a machine-readable label that identifies “what kind of thing” it is. For example, its nature might be “HTML documentation” or “XML Schema” or “CSS Stylesheet”. The purpose of a resource, with respect to the resource identified by the namespace URI, is a machine-readable label that identifies “what use” the thing is. For example, its purpose might be “validation” or “normative reference” or “specification” or “transformation”.

For example, here's a diagram of the model for some DocBook-related resources:

This section describes two formats deployed explicitly to address the question of namespace documents and a third format which can be seen as simultaneously providing a unified view of these two formats and also providing a model to make other new formats available.

For many applications of namespaces, it's valuable not only to be able to point to the namespace as a whole, but also to be able to point to terms within that namespace. Fragment identifiers are the obvious mechanism for achieving this. For example, http://www.w3.org/2005/xpath-functions/#matches is the URI for the “matches” function, a term in the XQuery 1.0, XPath 2.0, and XSLT 2.0 Functions and Operators Namespace, http://www.w3.org/2005/xpath-functions/.

If it would be valuable to directly address specific terms in a namespace, namespace owners SHOULD provide identifiers for them. It follows that if the namespace document is available in multiple forms (RDDL 1.0, RDF through GRDDL, etc.) that consistent fragment identifiers MUST be made available.

@@ list of natures, borrow from RDDL.

@@ list of purposes, borrow from RDDL.