atom feed90 messages in org.xml.lists.xml-dev[xml-dev] Pragmatic namespaces
FromSent OnAttachments
Micah DubinkoJul 31, 2009 4:06 pm 
COUTHURES AlainAug 1, 2009 3:35 am 
Amelia A LewisAug 1, 2009 7:43 am 
Kurt CagleAug 2, 2009 11:55 am 
Kurt CagleAug 2, 2009 12:30 pm 
Amelia A LewisAug 2, 2009 6:44 pm 2, 2009 9:07 pm 
Micah DubinkoAug 2, 2009 9:22 pm 
Micah DubinkoAug 2, 2009 9:40 pm 
Dave PawsonAug 2, 2009 11:20 pm 
Michael LudwigAug 3, 2009 8:30 am 
Kurt CagleAug 3, 2009 10:41 am 
Pete CordellAug 3, 2009 11:56 am 
Michael KayAug 3, 2009 1:46 pm 
Kurt CagleAug 3, 2009 4:42 pm 3, 2009 8:39 pm 
Pete CordellAug 4, 2009 12:37 am 
Tim BrayAug 4, 2009 9:44 am 
Micah DubinkoAug 4, 2009 11:17 am 
Micah DubinkoAug 4, 2009 10:55 pm 
Liam QuinAug 4, 2009 11:29 pm 
Dave PawsonAug 5, 2009 12:46 am 
Pete CordellAug 5, 2009 3:17 am 
Tim BrayAug 5, 2009 12:53 pm 
Liam QuinAug 5, 2009 1:46 pm 
Michael KayAug 5, 2009 4:45 pm 
64 later messages
Subject:[xml-dev] Pragmatic namespaces
From:Micah Dubinko (
Date:Jul 31, 2009 4:06:46 pm

Literally for years, people have been talking about how great it would be to use something like Java-style namespaces in XML instead of the current xmlns regime. For example

By scoping the solution down to just HTML syntax, I believe a reasonable solution can be crafted, and now that the W3C is focusing on "distributed extensibility" as a requirement for HTML5, the timing seems right to see how far a proposal in this direction can go. On the other hand, if this proposal doesn't work out, maybe it will permanently end the musings about how great Java-style namespaces would be.

I'm posting this on xml-dev for community input and feedback. I have no current association with the HTML Working Group, and this is my personal project, with no reflection on my employer. The format is an intermingling of requirements and proposed solutions. This is largely inspired by Tom Bradford's "clean namespaces" proposal, the version of which I linked to previously.

Requirement: Ask not if it is good enough, ask if it can be popular enough.

(Thanks to Douglas Crockford for the quote). This proposal will horrify the purists, but that's OK.

Requirement: this solution must not interfere with existing HTML elements or attributes

Point 1: Any element name with no dots in it is treated as HTML (including HTML rules on handing unrecognized elements)

Requirement: this solution must allow for distributed creation of globally-unique namespace names (including those outside of a consensus process)

Point 2: Any element with one or more dots in it is treated as an extension element. The portion after the last dot is considered the localname, and the the portion up to but not including the last dot is parsed as the pragmatic namespace name (or pname for short). Interfaces with existing namespace-aware APIs must treat the pname as the namespace URI. With the exception noted below, to prevent clashes pnames must be based on reversed DNS names.

Example: <head> <title>Document title</title> <com.example.project> <>123521123</> </com.example.project> </head>

In this example document.getElementsByTagName("id") would return the innermost element. So would document.getElementsByTagNameNS("com.example", "id")

Requirement: it is highly desirable to produce a document that will produce the same element names in HTML or XML

Point 3: Zero or more special attributes of the form using.<pname> may appear on the root element, and ONLY on the root element. The declarations have document-wide scope. The pname that appears after "using." is the one being declared. The value of the attribute is a space-separated list of localnames that represent boundary elements, in other words, upon reaching a boundary element, a new namespace gets applied to that element and all children (until encountering another boundary element).

Example equivalent to the previous: <html"project"> <head> <project> <id>123521123</id> </project> </head>

This structure will produce the same element names in an XML parser, and a straightforward transformation could convert it to true XML +Namespaces.

Requirement: widely-known namespaces must be parse to an equivalent DOM as xmlns

Point 4: In any extension element with only one dot, the token before the first dot is treated specially. Specifically, there exists a list of grandfathered namespaces, and associated namespace URIs. Interfaces with existing namespace-aware APIs must treat the grandfathered namespace URI as the namespace URI of the extension element.

Here is the list: (additional suggestions welcome)

atom docbook html math svg xbl xbl2 xforms xlink xml


<html using.math="math">... <p> E.g. <math><msqrt><mi>π</mi></msqrt></math> </p> ...</html>

In this example document.getElementsByTagName("mi") would return the innermost element. So would document.getElementsByTagNameNS(" ", "mi")

Requirement: must support HTML nested inside an extension vocabulary.

Point 5: Unless overridden, HTML documents are treated as if all localnames explicitly listed in the specification are HTML boundary elements.

Example: <html using.svg="svg"> <body> <svg version="1.1" viewBox="0 0 100 100" preserveAspectRatio="xMidYMid slice"> <rect x="10" y="10" width="100" height="150" fill="gray"/> <foreignObject x="10" y="10" width="100" height="150"> <body> <div>Here is a <strong>paragraph</strong>.</div> </body> </foreignObject> </svg> </body> </html>

Here the inner body element and its children are still treated as HTML.

Another example: <html using.xforms="model select1 range secret"> <head> <model>...</model> </head> </body> <xforms.input>... </body> </html>

In this case, "input" is already used as an HTML element name, so uses of it--even with the using statement at the top--need to be explicitly spelled out. Of course, the author could have overridden this by including "input" in the using statement, but then any regular HTML input controls would need to be spelled <html.input>. Just like in Java.

That's the entire proposal.

In practice, it may be inevitable that browser makers might bake in additional defaults, like using.math="math mi mo ms mn mtext" such that users can freely use chosen vocabularies with zero additional markup. Support for this outcome is an additional feature of this proposal.


I will be at Balisage this year. If you have comments or ideas, look me up. Comments on this list are welcome as well.


XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: Or unsubscribe: subscribe: List archive: List Guidelines: