I was just having time to start to think about namespaces ;-)
Let me, first, say that I now love namespaces. Like many, my first
years with XML were disturbed by namespaces : I didn't understand them
and many errors occurred due to this. It was like dark magic : add this
and that, add more if it still doesn't work... The no-namespace
capability is even more difficult to understand because it has to be
explicit ! I understand that HTML writers, who are usually not
programmers, hate namespaces, considering them as useless (the element
name is explicit, isn't it?) and problems cause.
I wouldn't say that today everything is perfect for me :
Misspelling is, for me, the most important concern because I'm just
using a smart text editor (Notepad++ is free and fast). With rendering
language such as HTML or SVG, it's easy to locate what is wrong because
it can be seen but, with XPath, there is no "unknown" element, just
"not found" elements !
- having a big list of xmlns attributes at the document element is
horrible and they are usually always the same (same prefix, same URI)
and when I try to reduce the number of them, I finally need one of them
- upgrading a namespace sometimes means changing every declaration
of it because of URI change
- copy/paste from different documents, where different prefixes are
used for the same namespace, requires delicate text editor substitutions
- misspelling in URI occurs (URI are too long, they should not
contain a year,...) and it's usually difficult to detect it immediately
- misspelling in element or attribute names in a specific namespace
Even some widespread XML libraries and engines have difficulties with
My first remark about Java-style namespaces is about a . or a : as
separator. The dot is now allowed in element names and I have already
seen some XML notations using it. I'm not sure it's a good practice
anyway and . as separator sounds like Java definitely.
Requirement: Ask not if it is good enough, ask if it can
be popular enough.
Yes, it's a very important point but I wouldn't like to reduce XML
possibilities either. Easy for non-programmers, powerful for others :
is it possible ?
(Thanks to Douglas Crockford for the quote). This proposal will horrify
the purists, but that's OK.
This might be a problem for XForms instance data. XSLTForms doesn't
generate an error when there is no prefix and no xmlns="" in the
instance data and, when people send me their forms for support, I
usually see that they don't bother with that. Yes, non-programmers try
to write programs sometimes...
Requirement: this solution must not interfere with existing HTML
elements or attributes
Any element name with no dots in it is treated as HTML (including HTML
rules on handing unrecognized elements)
OK. It sounds good !
Requirement: this solution must allow for distributed creation of
globally-unique namespace names (including those outside of a consensus
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.
In this example document.getElementsByTagName("id") would return the
So would document.getElementsByTagNameNS("com.example", "id")
ONLY on the root element is a problem for generic XML tools. The
Component Manager I wrote for XSLTForms development environment can
work for any XML document with its own namespaces, unknown by the
Component Manager itself. With XSLT, xsl:copy-of can be used for a node
from an external document, the stylesheet doesn't have to know each and
Requirement: it is highly desirable to produce a document that will
produce the same element names in HTML or XML
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
Example equivalent to the previous:
This structure will produce the same element names in an XML parser,
and a straightforward transformation could convert it to true
It's also a problem for XForms instance data.
A very good aspect of namespaces is to allow to mix data without
disturbing the programs interested in just one namespace !
Why not just say that, usually, using.<pname> attributes are on
the root element ?
Requirement: widely-known namespaces must be parse to an equivalent DOM
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)
In this example document.getElementsByTagName("mi") would return the
This kind of list should not change frequently. It sounds more than
I, personally, would like to add
Big companies, such as Microsoft, would probably have their own items
without asking others if they agree...
Managing a short list will not be easy...
One solution could be to limit it to namespaces frequently used in HTML
Requirement: must support HTML nested inside an extension vocabulary.
Unless overridden, HTML documents are treated as if all localnames
explicitly listed in the specification are HTML boundary elements.
<svg version="1.1" viewBox="0 0 100 100"
<rect x="10" y="10" width="100" height="150" fill="gray"/>
<foreignObject x="10" y="10" width="100" height="150">
<div>Here is a
Here the inner body element and its children are still treated as HTML.
<html using.xforms="model select1 range secret">
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
That's the entire proposal.
But compatibility problems would occur between different browsers and
different versions of the same browser. It's not a non-programmer
concern, isn't it ?
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
Thank you for this proposal. Yes, something has to be done and it
sounds much more easy this way.