Pragmatic namespaces

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
From: Micah Dubinko <micah.dubinko@marklogic.com>
To: XML Developers List <xml-dev@lists.xml.org>
Date: Fri, 31 Jul 2009 16:06:46 -0700
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 <http://www.xml.com/pub/a/2005/04/13/namespace-uris.html 
 > .

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  
archive.org 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>
     <com.example.id>123521123</com.example.id>
   </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 using.com.example="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 http://www.w3.org/2005/Atom
docbook http://docbook.org/ns/docbook
html http://www.w3.org/1999/xhtml
math http://www.w3.org/1998/Math/MathML/
svg http://www.w3.org/2000/svg
xbl http://www.mozilla.org/xbl
xbl2 http://www.w3.org/ns/xbl
xforms http://www.w3.org/2002/xforms
xlink http://www.w3.org/1999/xlink
xml http://www.w3.org/XML/1998/namespace

Example:

<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("http://www.w3.org/1998/Math/MathML/ 
", "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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]