The W3C has an answer to this question: There is nothing at all at the end of a namespace URI, except perhaps a 404 Not Found error. One reason the W3C wanted to avoid putting anything at the end of a namespace URI is that it wasn't clear what to put there. Should it be a DTD? a schema? a Java-content handler for processing the document? a style sheet? something else? There are simply too many good choices to limit developers to any one of these.
Unfortunately, this answer seems to be one that developers are unable or unwilling to hear. With few exceptions, namespace URIs are URLs, Uniform Resource Locators, and it's not unreasonable for users to expect a URL to locate a resource. However, namespace URLs are identifiers, not locators. Thus, the error logs of the W3C and other purveyors of XML specifications have been filling up with requests for nonexistent pages at the end of namespace URLs, and XML mailing lists are besieged with questions about whether one can run an XML parser on a machine that isn't connected to the Internet and is thus unable to resolve the namespace URL.
After addressing this issue again and again on various mailing lists, Tim Bray and Jonathan Borden decided to do something about it. If they couldn't convince developers that there wasn't anything at the end of a namespace URL, then maybe it would be a good idea to invent something to put there. What they came up with was the Resource Directory Description Language, RDDL for short. RDDL is an extensible XML application for documents that live at namespace URLs. RDDL is designed to allow both human readers and software robots to find any sort of resource associated with a particular namespace. Instead of putting one thing at the end of a namespace URI, RDDL puts a document there that lists all the machine-processable documents that might be available, including, but not limited to:
Schemas in a variety of languages (including RELAX, Schematron, the W3C Schema language, TREX, and others)
CSS, XSLT, and other style sheets
An RDDL document identifies each related resource by a resource element in the http://www.rddl.org/ namespace, which is customarily mapped to the rddl prefix. This element is a simple XLink (that is, it has an xlink:type attribute with the value simple) and its xlink:href attribute points to the related resource. Furthermore, the xlink:role attribute identifies the nature of the related resource and the optional xlink:arcrole attribute identifies the purpose of the related resource. An optional xlink:title attribute can provide a brief description of the purpose of the link. For example, this rddl:resource element points to a DTD for recipes:
xlink:title="DTD for validation"
This rddl:resource element points to a Cascading style sheet (CSS) for recipes:
xlink:title="CSS Style Sheet for Recipes"
The xlink:href attribute can contain any convenient form of a relative or an absolute URL. However, intelligent machine processing requires well-known URLs for common natures and purposes. The RDDL specification defines these natures and their well-known URLs:
CSS style sheet:
HTML 4 Strict:
HTML 4 Transitional:
HTML 4 Frameset:
XHTML 1.0 Strict:
XHTML 1.0 Transitional:
RELAX Core grammar:
RELAX Namespace grammar:
OASIS Open Catalog:
W3C XML Schema:
Furthermore, users can define additional natures for any resource that has a MIME media type. To do this, simply append the MIME type to the canonical URL for media-type registrations, http://www.isi.edu/in-notes/iana/assignments/media-types/. For instance, the MIME type for an Acrobat PDF document is application/pdf, so the xlink:role for a PDF form of the specification could be http://www.isi.edu/in-notes/iana/assignments/media-types/application/pdf.
The purpose encoded in an xlink:arcrole attribute provides optional, extra information that can suggest the intended use of the related resource, such as validation or definition. The RDDL specification identifies many purposes, including:
Furthermore, users can define additional purposes simply by pointing the xlink:arcrole attribute at a URL describing their purpose.
RDDL documents can contain any number of rddl:resource elements. Software can use any XML parser to extract and inspect all the rddl:resource elements in an RDDL document. However, this doesn't really solve the original problem, which is that the user types a namespace URL into a browser's location bar and expects to see something. But browsers don't know how to display this RDDL vocabulary. In fact, since all the RDDL information is encoded in attributes, a browser looking at one of these RDDL elements would likely present a blank page. Style sheets could alleviate this somewhat, but that limits your audience to users with XML-capable browsers, a relatively small fraction of the installed base.
The solution to this problem is quite ingenious. Instead of just putting up a document in a new XML vocabulary, RDDL is embedded inside HTML, using namespaces, XHTML modularization, and XHTML Basic. The root element of RDDL documents is html. Inside an RDDL document, you can use all the familiar tags from HTML, such as <p>, <br/>, and <h2>. However, you can also put an rddl:resource wherever you'd put a p element. Furthermore, the rddl:resource elements themselves can include the same HTML markup as a div or span element. For example, a complete RDDL document incorporating the two previous rddl:resource elements might look like:
Click here to view RDDL example.
A human looking at this page in a Web browser will see a legible description of the XML application and the material available for use, while the rddl:resource information will remain hidden. A software agent, by contrast, can ignore all the HTML and extract the rddl:resource elements.
Development of RDDL is proceeding at a rapid pace. The current version of the specification is available, as an RDDL document, of course. Community input and implementation experience is desired. Most of the discussion takes place on the xml-dev mailing list. While XML developers will likely never be required to use RDDL, anymore than they're required to use namespaces today, RDDL seems likely to become a key part of the semantic Web in the future. With RDDL, namespace URIs are no longer just character strings used to disambiguate similarly named elements and attributes. Namespace URIs are now the gateway to a rich soup of resources to help programs and people understand and process XML documents.
Elliotte Rusty Harold is a noted writer and programmer, both on and off the Internet. His Cafe au Lait Web site has become one of the most popular independent Java sites on the Internet, and his spin-off site Cafe con Leche for XML News and Resources has become one of the most popular XML sites on the Internet. Elliotte is the author of O'Reilly's Java Network Programming, Second Edition and coauthor of XML in a Nutshell.
Return to xml.oreilly.com
Copyright © 2009 O'Reilly Media, Inc.