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
http://www.dsdl.org/dsdl-9-rev061103.pdf
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.
