I'll cut your ass in half and leave you with a semi-colon
—Mr. Man
QNames in content have been on my brain today. See a follow up posting
for more on why.
First of all I think we should find a new name for this phenomenon,
because I don't think QNames qua QNames are key to the problem. For one
thing, you have the problem even if you only use a prefix in content, as
XSLT does in, say the extension-element-prefixes, or XPath in
html:*/html:span (the second step is a QName, but not the first). I
think a better name for this problem is "hidden namespaces" because
that's exactly the problem: the document depends on a construct that is
hiding a namespace in a separate layer where generic processing cannot
see it.
Whatever the name, I re-read today a couple of important documents
regarding the issue. First of all there is the TAG finding on
QNames, which is
unfortunately not much more than an agglomeration of existing wisdom.
Norm Walsh, the editor of that document wrote of a more radical
direction as part of his "XML
2.0" article. I like his
ideas (though I'm partial to Jeffrey Yasskin's ampersand
variation, and I
hope conversation soon drives towards something along those lines. XML
is almost ten years old, and I see nothing wrong with a bit of a shake-up.
Until then, I think we can deploy two safeguards to protect ourselves
from the subtle problems of namespaces. I call them: "sanity within the
document, and registries without". The two components are very
different in character.
Firstly, we need to discard the idea of in-document scoping of
namespaces. It seemed a great idea at the time, even to me, but in
practice it's a mess, and Joe English was the first one to illuminate
the mess in the light of a brilliant
metaphor (Google cache of original since XML-DEV is down now).
(See my article "Principles of XML design: Use XML namespaces with
care"
for more on this). If we can rely on sanity in XML documents we can at
least simplify state processing a good deal. Ideally all the XML
sources in an XML processing pipeline would emit sane XML.
Secondly, I think the time has come for namespace registries. It would
definitely be nice to build on the unfortunately stalled
RDDL, but whereas the goal of RDDL is to
provide human readable information, what I think we really need in a
namespace registry is a little nugget of machine-readable data.
Drumroll please...
A list of preferred prefixes for a namespace (supporting lookup of
namespace name to well-known prefix, and vice versa). I know this will
be controversial. Prefixes are supposed to be insignificant. Users
should have flexibility to use whatever prefix, blah blah blah. I'm
sorry, but that's all theoretically nice, but we have practical problems
to solve. The fact that the most powerful constructs in XPath depend
for their semantics on the whimsy of prefix choices should bother you a
bit. The fact that Canonical XML had to abandon the idea of normalizing
prefixes should bother you even more. It's time to just say that xsl
means "The XSLT namespace" (yeah, yeah: "what version?" etc.—hard
problems would still remain) and that if you choose to use it for a
different namespace, you're technically compliant to namespaces, but
you're asking for a heaping help of trouble, buddy.
For now I'm just throwing out ideas to help organize my thoughts, and
for discussion. It seems to me that if we could rely on authors and
tools, supported by a registry, to produce sane documents that (wherever
possible) used essentially reserved prefixes, including, of course, for
hidden namespaces, we could simplify namespace-aware processing a great
deal. I can think of some practical hurdles for the registry idea, but
I can't think of any reason why it's not even worth a try.
[Uche Ogbuji]
