Rick,


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.