atom feed90 messages in org.xml.lists.xml-devRe: [xml-dev] Pragmatic namespaces
FromSent OnAttachments
Micah DubinkoJul 31, 2009 4:06 pm 
COUTHURES AlainAug 1, 2009 3:35 am 
Amelia A LewisAug 1, 2009 7:43 am 
Kurt CagleAug 2, 2009 11:55 am 
Kurt CagleAug 2, 2009 12:30 pm 
Amelia A LewisAug 2, 2009 6:44 pm 2, 2009 9:07 pm 
Micah DubinkoAug 2, 2009 9:22 pm 
Micah DubinkoAug 2, 2009 9:40 pm 
Dave PawsonAug 2, 2009 11:20 pm 
Michael LudwigAug 3, 2009 8:30 am 
Kurt CagleAug 3, 2009 10:41 am 
Pete CordellAug 3, 2009 11:56 am 
Michael KayAug 3, 2009 1:46 pm 
Kurt CagleAug 3, 2009 4:42 pm 3, 2009 8:39 pm 
Pete CordellAug 4, 2009 12:37 am 
Tim BrayAug 4, 2009 9:44 am 
Micah DubinkoAug 4, 2009 11:17 am 
Micah DubinkoAug 4, 2009 10:55 pm 
Liam QuinAug 4, 2009 11:29 pm 
Dave PawsonAug 5, 2009 12:46 am 
Pete CordellAug 5, 2009 3:17 am 
Tim BrayAug 5, 2009 12:53 pm 
Liam QuinAug 5, 2009 1:46 pm 
Michael KayAug 5, 2009 4:45 pm 
'Liam Quin'Aug 5, 2009 4:50 pm 
Pete CordellAug 6, 2009 12:23 am 
Pete CordellAug 6, 2009 12:36 am 6, 2009 12:58 am 
Michael LudwigAug 6, 2009 1:37 am 
Kurt CagleAug 6, 2009 1:47 am 6, 2009 1:51 am 
Michael KayAug 6, 2009 2:10 am 
Michael KayAug 6, 2009 2:21 am 
Michael KayAug 6, 2009 2:25 am 
Pete CordellAug 6, 2009 2:39 am 
53 later messages
Subject:Re: [xml-dev] Pragmatic namespaces
From:Kurt Cagle (
Date:Aug 3, 2009 10:41:46 am


Unless a broad variety of people participate at W3C, it can be taken in

any direction. Like almost any standards body, participation is the key.

This is a chicken & egg type of problem. Participation in the W3C, as you well know, is both expensive and time-consuming. This usually means that those who are involved with the W3C at a standards level are usually stretched to be able to participate in all of the domains that they are involved with, while there are many others who, especially in this day and age, can't participate at all, save by the proxy commentary process, because the costs involved are too high (fees, partially, and the additional costs of participating in the events themselves). This serves to keep the pool of those who can participate fairly small and usually overworked.

The syntax of DTDs is not immutable. If the HTML groups would like a form of DTDs with namespace-awareness, the SGML standard could be changed, as it was to accomodate XML. Indeed, there already is a specification for namespace-aware DTDs, prepared as part of ISO DSDL. You can read a draft at

While I think this is a necessary start - the namespace issue with DTDs has

impact far beyond HTML - the key question is convincing the HTML WG that namespaces are necessary (or at least some mechanism exists for extensions that can convey the same information). The mechanisms for change exist - the issue is whether the will does.

I think we need to consider the difference between server-side and client-side extensions. The XHTML/namespace mechanism seems fine for server-side extensions, processed at the server. But it has not thrived for the client-side.

But this assumes that you can cleanly separate the functionality between client and server, and I'd argue that the current situation is a rather ugly hack that will likely only be perpetuated with HTML 5. So long as your target is a small handful of web browsers, people are content to live with it, but we're increasingly moving into two modes - one where HTML is becoming a persistent document format for encoding within other environments (Atom for instance), the other where mobile devices have created a proliferation of browser mechanisms - where the need to instantiate that HTML just to process it is both expensive memory wise and a vector for viruses. Beyond that are component widgets, which are in effect localized browsers.

I'm not trying to argue that the current namespace standards are adequate - I'm not sure that anyone can realistically argue that - but I fear that we're throwing the baby out with the bathwater if we assume that because the implementation itself is bad, the need for some form of namespace mechanism is not there.

Also, there is in my mind a clear difference between vocabularies that add different functionality in branches (e.g. MathML, SVG, etc) and vocabularies that decorate or enhance or interleave with existing HTML (e.g. RDFa). The former unignorable, heavywieght and handled by plugins and the latter ignorable, lightweight and handled by the normal HTML mechanism (no namespaces).

Actually RDFa is an interesting case here, because it bypasses namespaces by inducing CURIEs (which are contextual namespaces), though with that particular proposition shot down I'm not really sure where RDFa itself sits. Most document enrichment systems either serve up their content as XHTML + namespaced content (and count on the "broken-ness" of most HTML processors to not throw an exception when namespaces are encountered) or they create faux namespaces (dot notation is not as rare as may be supposed there) in order to avoid term collision.

The one spec that I think tests HTML the most is XForms. MathML and SVG are generally self-contained - even with SVG's <foreignObject> it is typically the SVG processor that implements foreignObject rendering, not the HTML renderer (Firefox is an exception, however, and I think goes a long way to showing that if you do integrate renderers into the core HTML renderer you add considerable flexibility that plugins by themselves can't handle). XForms, on the other hand, is specifically designed to be integrated into HTML, has context that is dependent upon HTML elements, and is typically spread out over the entire HTML space.

Thus, I'm not really sure I'd agree with your argument here, especially moving forward.

So I would suggest that at least some of W3C's problems with namespaces

are of their own creation (without implying blame or second-guessing them): HTML 4 was in effect frozen where it would have been better to let it continue to evolve. So namespaces became the only tool for evolution, and since namespaces were never intended to be the only tool in the toolbelt (i.e. vocabularies continue to evolve even within a namespace) it is no surprise they are deficient. HTML 5 addresses this backlog.

Agreed on the problem with freezing HTML 4.

Consider something, however: the HTML philosophy was a highly conservative one - if you needed new functionality that wasn't part of the specification, you would have to subvert a <DIV> or <SPAN> element (or fall back on <OBJECT>) through the use of an attribute (class originally, though that's now become far too overloaded, so now they're adding role). This added complexity to addressing, far more in fact than is generally added with namespaces. I have no problem with the HTML 5 house-keeping, save for the necessity of having to do it. It *may* even be enough to move HTML into a mode where you don't have to build hacks in order to build contemporary web pages.

All of this gets back to the fundamental problems of versioning and revision - finding that sweet spot that allows for both a canonical implementation and a mechanism for extending the language into areas that it was not originally envisioned to solve. I'd be perfectly happy to see something besides the xmlns: approach to namespaces, but I see no rational reason for not incorporating some form of distributed extension mechanism into HTML. HTML 4 was solidified before namespaces were even off the conceptual drawing board, so it wasn't seen as a critical part of the language. Now, I'd say its essential.

Because if it chooses to cede this point, then for all intents and purposes the XML movement is dead.

Calm down Kurt, it would just shift venues. If there is a market

requirement for it, and if W3C is not interested, then people can ask SC34 to put out an ISO XML. But don't forget that there are other XML-using groups in W3C: SVG, MathML etc. The HTML WG is not the only voice in the marketplace. (And it is good to have a variety of different voices, even if some alarm us!)

At this stage, HTML dwarfs XML, and I'd argue that a significant reason for the lack of traction of other XML standards has largely been because HTML doesn't incorporate it. HTML is still the lingua franca of the web, and the more that HTML diverges from XML, the harder it is to justify the other XML standards - especially on the client, where it needs to be. If HTML has an HTML namespace mechanism (hns: for sake of brevity) then the transformation between HTML and (x)HTML is round-trippable - you don't lose any information, and HTML becomes simply another XMLish syntax that can be built into processors. Without an hns: mechanism, there will always be a wall between the two formats, and HTML will continue being just an endpoint format rather than a pipeline format, and we'll continue trying to create unnecessary kludges in trying to process HTML content. This is the argument I was trying to make (albeit perhaps with a bit too much hyperbole) with "the XML movement is dead" comment.