Hey Micah,
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 :
- 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
later...
- 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
occurs too...
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 !
Even some widespread XML libraries and engines have difficulties with
namespaces !
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.
(Thanks to Douglas Crockford for the quote). This proposal will horrify
the purists, but that's OK.
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 ?
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)
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 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")
OK. It sounds good !
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.
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
every namespaces.
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
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")
It's pragmatic.
This kind of list should not change frequently. It sounds more than
reserved prefixes.
I, personally, would like to add
xsl http://www.w3.org/1999/XSL/Transform
xsd http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance
xbrl http://www.xbrl.org/2003/instance
xbrll http://www.xbrl.org/2003/linkbase
ifrs http://xbrl.iasb.org/taxonomy/2008-03-01/ifrs
...
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
documents only.
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.
Yes !
That's the entire proposal.
Great !
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.
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 ?
Thank you for this proposal. Yes, something has to be done and it
sounds much more easy this way.
Best regards,
-Alain
|
