[slightly edited: URI references updated] From: Arjun Ray Newsgroups: comp.infosystems.www.authoring.html Subject: The Namespace Bogosity Date: Sun, 26 Aug 2001 18:40:37 -0400 Organization: FUDGE Dispersal Systems Message-ID: <0euiot4uvoushj2sa0dg3bfqjvh89t1mbk@4ax.com> In , Henri Sivonen wrote: | what [...], in your opinion, is wrong with XML namespaces? It is unnecessary and insufficient to solve any problem worth solving. But, much more importantly, as long as it exists and it commands the enthusiasm that the W3C's hysterical boosterism is drumming up for it, it has the (intended) effect of inhibiting consideration of - or even interest in - alternatives. "Mindspace" is finite. Preoccupy people with bogus panaceas and real solutions will go unconsidered. 1. First, some history. It started with multipart names, a syntactic device extruded from the murky depths of what eventually became the W3C's Metadata Activity. Some people thought colonified names were kinda k3wl - it seemed to solve a problem in what eventually became RDF, or more precisely, the XML "serialization" thereof - so there was born a need to retrofit a justification. The first mention of "namespaces" for XML in the multipart-name sense was this, part of a slew of proposals dumped somewhat abruptly on the ERB/WG: http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997May/0195.html (Note: Jean Paoli didn't participate in the discussions that ensued. I seriously doubt that he wrote this - he knew his SGML - rather, he merely presented it, being the senior rep from Microsoft. The actual "defence" of the proposal was conducted by a new arrival, who soon proved to be utterly ignorant of SGML, and whose repeated use of the non-SGML jargon found in this piece is, to my mind, a pointer to the real authorship. The advantage of being severely SGML-challenged was that he could go on babbling without having to admit he couldn't grasp the various objections, and the advantage of being a Microsoft rep was that ignorance of SGML was no bar to his participation, not only in the WG but also on the ERB, where perforce his evasive top-posted drivel had to be given the time of day.) I won't save you the trouble of reading 500+ followups. If I say that the proposal was thoroughly trashed, you should not believe me - find out for yourself. A couple of months later, the ERB/WG was reorganized into the WG/SIG, and the hitherto publicly archived mailing list was taken in-house. There are another 1800+ messages on the "namespaces" maguffin that the public will never get to see. Nothing new was said for namespaces. OTOH, the objections crystallized into at least two counterproposals that were simply *ignored*. They were elaborations of this: http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jun/0274.html The essentially political decision had already been made that XML will have namespaces in the form of colonified names, and therefore it was the XML-WG's job - oops, duty - to rubberstamp, somehow, a device that gave some C++ programmers like that twit from Microsoft warm fuzzy feelings. That "somehow" is the reason for the annoying vagueness of the spec. All specifics were thoroughly and comprehensively demolished on the w3c-xml-sig list - check the early drafts and note how some "examples" simply and quietly uh, disappeared. (This is why that archive will never see the light of day.) Later, of course, it became important to rewrite the history more um, comfortably. http://mailman.ic.ac.uk/pipermail/xml-dev/1999-September/015411.html (Yes, I was implying that the pope had just spewed utter bullshit.) 2. Next, the spec. The spec itself is a stalking horse. Ostensibly it's about - and only about - "universal" or "globally unique" names. But in fact, the "Motivation and Summary" section is a non-sequitur in its entirety, because such names - "universal" or "globally unique" or whatever - are *not* necessary. http://groups.google.com/groups?selm=38068643.3385157599@news1.newscene.com [Also here: https://www.nyct.net/~aray/sgo/afintro.txt] See also, http://groups.google.com/groups?selm=01bc90ae$6fa19160$3219c1cf@w.kimber Colonified names was a solution in need of a problem. Once all the "serious" arguments had been discredited, all that was left was vague philosophizing about universal names - more than that was not going to find consensus even for a Working Draft. (While the WG/SIG lasted, Namespaces never made it beyond WD status. Once the groups were dissolved in Sept 98, Namespaces sailed through to Recommendation in short order. The operative word was "attrition".) The problem, naturally, was that people were still likely to read into the spec all the arguments and motivations that had been discredited. Indeed, the *existence* of the Rec (never mind what it said or did not say) could - and in the event, would - be used to conclude that those arguments and motivations were well-founded. 3. Thus then, the supposed benefits. There is a cluster of arguments to the effect that colonified names are "straightforward syntax". One canonical article is http://www.xml.com/pub/a/1999/01/namespaces.html It must be "straightforward syntax" to *create* the possibility of significant whitespace between tags, right? That's why you must write stuff like "Simon St. Laurent" all on one line. It must be "straightforward syntax" to create the possibility of mixed orders - why does the next line start with rather than ? The real issue, of course, is the "necessity" of all that extra element structure to begin with. Compare the first example with the reworking here: http://lists.xml.org/archives/xml-dev/200002/msg00609.html A second set of arguments has to do with "combining DTDs" in the face of name clashes. The case is set out in Ron Bourret's FAQ: http://www.rpbourret.com/xml/NamespacesFAQ.htm#q8_5 And here is another reworking: http://www.nyct.net/~aray/sgml/demo/dept/ Note that this remark in the FAQ is demonstrably false: : You can also see that XML namespaces played a vital role in this : process -- they allowed us to combine the documents without changing : the local names of any of the element types. In fact, *all* "local names" have been changed. The fallacy at work - that "local names need to be unchanged" - is a deepseated one, and at the heart of all the examples purporting to illustrate a "problem". A central tenet of SGML is that a DTD designer have complete freedom in choice of names: the point is to define a coherent document type. The issue of binding "local names" to *externally fixed* names is not one of *syntax*, but one of annotation. http://lists.w3.org/Archives/Public/www-html/2000Jan/0217.html IOW, you always need a map to fix associations, even if it happens to be a trivial identity transformation. http://www.nyct.net/~aray/notes/wek-namespaces.txt Note how at the end Eliot uses arbitrary generic identifiers (X, Y, Z, etc) to place *all significant* information into attributes. It should be clear that element type names are *values* (of a special kind of attribute, whose taxonomic function is to group names.) The point (about "rearranging" generic identifiers) is repeated here: http://lists.w3.org/Archives/Public/www-html/2000Feb/0072.html What the Namespace advocates are forced to deny is the ubiquity of multiple taxonomies. When you write stuff like , what you're really doing is annotating the same *data* with respect to two different taxonomies (or analytic schemes) simultaneously. You are forced to use extra element structure because the GI does not take *more than one* "namespace prefix". The correct solution for the general problem of *multiple* associations cannot be a device that allows only one! This is not a problem, you say? Well, look at this: http://www.w3.org/TR/xlink-naming/ Now why do you suppose that XLink and (X)HTML *can't* share a HREF attribute? Tsk. Tsk. -- "The bottomline is that it is really difficult to solve a problem when the problem does not exist." - Masataka Ohta.