Many applications of XML are designed to process XML resources in combination with other related or supporting resources. Such resources currently include DTDs, stylesheets, RDF metadata, human-readable documentation, and executable code; many other types of related resource are in active development. In general, there is no standardized interoperable way for an XML resource to include information to aid applications in retrieving such related resources.
W3C recommendations currently provide syntax for XML documents to include pointers to DTDs and to stylesheets. These methods are ad-hoc, not compatible with each other, and represent nobody's idea of a general solution to the problem of retrieval of related resources.
The number of resource types that are potentially related to an XML resource is growing rapidly. Within a year or two, the list of types may reasonably be expected to include the following.
In many cases, it is valuable for an XML resource to aid applications using it find such related resources. In the absence of such aid, applications which need to use such resources will implement a selection of ad-hoc hardwired techniques for finding them, with no expectation of interoperability. It is undesirable for each application to embed idiosyncratic markup in the document to aid in this (as is the case with DTDs and stylesheets). It is even more undesirable for the applications to use built-in hardwired rules based on filenames, extensions, or the like.
The following are desirable characteristics of a related-resource-discovery solution:
Schemas are metadata resources, usually declarative in nature, that describe the organization, content, and (in a limited sense) meaning of an XML document. The widespread deployment of schema technology is expected to bring a substantial increase in the richness and utility of the Web as a whole.
However, across the space of applications, it is clearly the case that schemas are merely one type of related resource, whose importance to the other types is often high but always application-dependent.
XML Namespaces provide a mechanism for universalizing the names of XML elements and attributes by turning them into two-part objects, the added part being a URI. The combination of the URI and local name is guaranteed unique across the spectrum of applications and provides a robust and efficient means to group the universe of names into named vocabularies ("namespaces").
The fact that a namespace name is a Uniform Resource Identifier has led many to the not-unreasonable conclusion that it Identifies a Resource, and that this resource serves a definitional function for the namespace.
This was not the intention of the Working Group that produced the namespace specification, simply because there was no facility available that is able to specify the wide range of semantics that can be associated with a vocabulary. However, the notion that the namespace name ought to be usable for the retrieval of something is plausible and worth serious consideration.
For example, should a related-resource discovery facility take the form of an XML document containing links to some related resources and the content of others, it would be unsurprising to expect to use the namespace name to retrieve that.
Furthermore, in such an XML document, namespace names are attractive candidates for use in identifying the types of the related resources.
This problem is not in the future. Applications are already doing related-resource discovery today, and will do so at an increasing rate. If no interoperable, scalable method of doing this is available, there will be no interoperability or scalability in industry practice.