Balisage Paper: Automatic XML Namespaces

Default (#FIXED) attributes in a DTD

The idea here is to have a document type definition that supplies xmlns:svg and so forth as #FIXED attribute values. This would be interesting if Web browsers fetched DTDs. One could consider JavaScript to fetch the DTD from the W3C servers, but W3C can't afford the bandwidth, and there are file access restrictions on JavaScript that may make a persistent cache or XML Catalogue approach hard to implement; in addition, both the SYSTEM and the PUBLIC identifiers are fixed, so one cannot serve HTML documents with server-specific values. This DTD-based approach might work fine outside the HTML world, but it turns out that today's Web browsers reject documents containing qnames if the prefix has not been explicitly bound to a URI. This means that a document would not be considered as well-formed without the DTD: progressive rendering as the document loads would have to wait for the DTD, and an unavailable DTD would prevent the document from loading. Worse, since the browsers don't fetch the DTD themselves, the approach of defining default prefixes in a DTD can only lead to documents that the browsers can't load. Since our goal is to reach out and build bridges between HTML and XML worlds and we must (regretfully) dismiss this approach.

Information Technology — Document Schema Definition Languages (DSDL) — Part 8: Document Semantics Renaming Language (DSRL)

ISO Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee SC 34, Document Description and Processing Languages has recently produced a draft of their Document Semantics Renaming Language (DSRL) . This document does not appear to make clear how a DSRL mapping is located, given an instance document, although separate evidence private communication suggests a plan to use a processing instruction. Possibly the ISO committee would be amenable to an alternative suggestion that is more likely to work in HTML-based Web browsers, since processing instructions interfere with PHP processing, and also cannot portably appear before the end of the document's head element, which may be too late in a world of progressive rendering.

The DSRL specification describes a powerful mechanism to map elements, attributes, processing instructions and entities (!) in the XML document to alternates. You can map any element to a new (namespace, element) combination, where the replacement is part of a validating schema. This specification is almost certainly too complex to implement in the few hundred bytes of JavaScript we can allow ourselves, although the possibility of defining HTML entities using an XML syntax is very alluring. DSRL uses XPath to specify the context in which remapping is to occur. One could thus map every third svg element in the document, if desired.

Overall, DSRL seems very promising. It appears to do what is needed. But, like a US Congress bill, it comes with a lot of additional baggage, some of which is problematic for us, and also is some missing functionality we need:

JavaScript-based solutions

The trouble with a purely JavaScript approach is that it works in a Web browser but not in a pure XML environment. It is a bridge that reaches only one shore of the river. But JavaScript can indeed be part of a solution, as we shall see.

First, we should note that, as things stand (April, 2009), HTML 5 says that certain elements, such as svg and math, are to be placed in the namespaces one might expect automatically. Unfortunately, existing Web browsers do not behave this way. Once HTML 5 becomes a W3C Recommendation one might reasonably expect to see implementations, but a great many people will still be using older browsers. This also presents an incompatibility with XPath used from JavaScript, because older browsers put everything in the default (non) namespace.

One can use JavaScript to place elements in the right namespace to make older browsers work the same way as newer ones, and this leads us towards a possible solution.

We should note, however, that any JavaScript that changes the DOM tree representation of the document might break other scripts, so our route to a short-term solution is not without problems.

Another compatibility issue is that XPath name test expressions with no namespace match only elements in the default namespace; a request has been made to bless the idea that they also can match elements in the HTML namespace. There is ongoing discussion in this area at the time of writing.

Disruptive Approaches

In the interest of completeness, it is worth mentioning an approach to changing namespaces that are incompatible with current practice. Ian Hickson has suggested [Hixie2006] adding micro-syntax within the xmlns pseudo-attribute, after the namespace URI, to allow a search path of namespaces. This would cause interoperability problems with existing XML software, but does show that others have considered this problem space in the past. Private communication tells the author that others have also given thought to this problem.

The Automatic Namespace Definition

An automatic namespace definition file is a simple XML document. It does not itself use a namespace, and does not need a DTD (although there is one) or schema (although you can have those too if you like). Let's start with a simple example:

<ns>
  <element>
    <name>svg</name>
    <uri>http://www.w3.org/2000/svg</uri>
  </element>
</ns>

The example says that whenever an element called svg is encountered, it introduces a new default namespace, with the given URI, which will apply both to it and to all its children, unless of course they are themselves listed in a namespace file, or unless they have explicit namespace bindings in the document.

This much one could do with DSRL, except that we have not used a namespace declaration for our namespace definition file itself. We also need a way to connect the namespace definition with the document; if we are in an HTML document, we could use a link:

<link rel="ns" href="ns.xml" />

This markup would go in the HTML head, although it is only needed if your namespace differs from the HTML 5 default, or if you are using XHTML. For older (i.e. all existing) browsers we also need to add a link to some JavaScript to make it work:

<script type="JavaScript src="ns.js" />

This is more complexity than declaring the SVG namespace, so it's hard to imagine people doing it. But what if we define several namespaces in one ns file?

<ns>
  <element>
    <name>svg</name>
    <uri>http://www.w3.org/2000/svg</uri>
  </element>
  <element>
    <name>math</name>
    <uri>http://www.w3.org/1998/Math/MathML</uri>
  </element>
</ns>

Now we are starting to make some headway, because although we added a lot of garbage, we don't need to change the declarations in the document. We could still do this with DSRL, or by putting the namespaces right into that JavaScript code. Now suppose we want to add the Enterprise Access Control Markup Language (invented for the purpose of example), EACML, and that we have a separate eacml.ns file that defines its element and namespace. We'll go back to our SVG-only example to keep the example listing shorter.

<ns>
  <element>
    <name>svg</name>
    <uri>http://www.w3.org/2000/svg</uri>
  </element>
  <element src="eacml.ns />
</ns>

Perhaps this markup is a little odd, but the idea is to have an analogy with HTML script elements. In addition, a non-empty element can supply a namespace URI, so that if the software recognises the URI, it does not need to fetch the ns file.

For XML documents in general, we could use an attribute on the top-level element (or any beneath it):

<mydocument xml:ns="ns.x" />

Such a declaration would need the blessing of the W3C XML Core Working Group, and at the time of writing has neither been proposed to them nor discussed by them.

<ns>
  <element>
    <name>svg</name>
    <uri>http://www.w3.org/2000/svg</uri>
    <attribute>
      <name>href</name>
      <uri>http://www.w3.org/1999/xlink</uri>
    <attribute>
  </element>
</ns>

Changing DSRL

Since DSRL already exists, it seems reasonable to ask how it could be changed to support automatic namespaces.

Although DSRL is not exactly aligned with automatic namespaces, it seems worth exploring further.

Conclusions and Ongoing and Future Work

Automatic Namespaces can considerably reduce the amount of syntax at the start of XHTML documents. They can also legitimize HTML 5 parsing, by having a default namespace file that specifies the behaviour, a sort of in-browser thought experiment. Automatic Namespaces can also help with other XML applications, because although currently you'd need to use (say) XSLT to process the namespace file and the instance, this is a straight forward thing to do in may pipeline-based work flows.

Links to other resources, such as schemas and style sheets, human-readable documentation and more could arguably live in the same namespace file in the future. The mechanism proposed is easily extensible by adding new elements.

A simple mechanism that can be implemented in JavaScript for XHTML documents can also be useful for more general XML, and could help to give a way to consider HTML 5 documents to have mixed namespaces without, in most cases, any need to declare them.