xmlhack: "Clean" namespaces

While Namespaces in XML continues to periodically surprise developers with new questions, Tom Bradford has offered a "clean" approach to namespace handling.

Clean XML Namespaces starts with a slightly different set of priorities than Namespaces in XML:

"It is not meant to be a specification that would require additional APIs, and it is not meant to replace formal namespaces. The objective is to define a simple way to non-invasively represent XML namespaces with simple qualified naming patterns."

Clean namespaces use a lexical approach to identifying namespaces rather than requiring processors to map prefixes to namespaces values defined in attributes. While the amount of information to be stored in prefix is somewhat verbose, Bradford notes that "terseness is not what XML is about."

Like Namespaces in XML, the namespace identifier is set off from the local name using a colon, but the namespace information is contained in the prefix itself, rather than in a mapping to a separate URI declaration. These prefixes may optionally be given declarations conforming to Namespaces in XML, allowing both approaches to operate simultaneously.

Related stories:

"Clean namespaces" do avoid the URL convention and I think that you are building your conclusion on the false assumption that these names need to be reversed and translated into URLs.

I see them more as just similar to Java package names.

Nobody seems to want to translate "com.jclark.xsl.sax" as "http://sax.xsl.jclark.com"; and thus nobody will complain if there is nothing at this locations and if sax.xsl.jclark.com is a non existant host name.

What I find rather clever with this proposal is the compatibility provided with Namespaces in XML 1.0 and that you could write:

<org.dbxml.cfg.math.geometry:element xmlns:org.dbxml.cfg.math.geometry="http://dbxml.org/whateverpath/doc.rddl">;

It's verbose, for sure, but it's preserving the compatibility with both namespaces systems and gives you a way to assign a URI with your "clean namespace".

Although I can see advantages of using unique namespace prefixes following the Java package naming convention to associate element types and attributes with a "clean" namespace, I foresee a bit of a problem with the proposed method for APIs to expose clean namespaces as formal namespaces.

Reversing "org.dbxml.cfg" and prepending " http:// " to get " http://cfg.dbxml.org " may be fine if an organization only defines one namespace. However, what if an organization wishes to have mutiple namespaces, each of which they may wish to continue following the Java package naming convention and organize these in some sort of complex hierarchy. For example, following the convention defined in this proposal, the clean namespace "org.dbxml.cfg.math.geometry" would be exposed as " http://geometry.math.cfg.dbxml.org ", which gets into the argument of whether something actually resides at a namespace's URI/URL (organizations certainly aren't going to construct their server architecture around XML namespaces).

Why not just avoid the "URL-as-namespace" convention altogether and, in our example, expose clean namespaces as a formal namespace similar to "cns:org.dbxml.cfg.math.geometry"?

During the initial namespace discussions, I proposed that URLs should be allowed as the namespace name, less delimiter characters that would confused XML. (I think just adding "/" was as far as I suggested.) This was not adopted because of the length of names and because they wanted full URLs, not some subset.