Strongly agreed. In that regard, I'm deeply reluctant to accept the
"shortcuts" (registry) that Micah proposed, because it seems to me that
these would soon become the only things supported.
Now ... even something like Flash, now so widespread, would have had no
chance of adoption and uptake without *extensibility* (and I will
perhaps be excused for emphasizing the word, since I am prouder of
having worked for the company of that name than of any other). I will
grant that IE offers a poor platform for namespace-based (or
equivalent) extensibility, but it seems to me that in order to enable
the future of the web, to make it a place where small, dedicated groups
can introduce something game-changing, that extensibility paradigm is
of paramount importance.
Yup. IE's playing catch-up now, however, and I suspect that with Chris Wilson
moving on, it may very well be to IE's advantage to actually be the advocate
for namespaces moving forward; the opportunity of using namespaces as
flags for specific schematic-oriented sub-processing is simply too obvious not to
take advantage of, and it is already a fairly significant feature of XAML/WPF.
I think it's verbosity as much as complexity. You will note, I hope,
the "namespace minimization" that I mentioned in my post; why should I
have to tell the processor the *namespace prefix* of the element that
I'm closing any more than I should have to repeat the attributes of
that element? I'm persuaded that permitting those to be dropped would
have no impact on well-formedness (although I admit that discussions of
minimization are likely to lead into a swamp, because well formedness
and minimization are clearly at odds, in a large number of cases that
can't be dismissed as "corner"). Arguably, XML's verbosity
(effectively requiring the equivalent of a comment on every equivalent
of a closing brace in C } /* if */ } /* while */) is precisely what
makes it robust enough to have achieved the levels of adoption that it
has seen.
In terms of verbosity, the idea of using something like XLink rather
than "href" in attributes (XLink is, in my opinion, vastly
overspecified/overengineered for the common case, leading to dismissal
of the opportunities that it provides for more sophisticated usage) is
equally damning. And neither DTD nor W3C XML Schema make it easy or
convenient to say "oh, you can use any attribute from a different
namespace on any element here". It's painful in DTD; it's exceedingly
tedious (and consequently likely to not happen, for at least some
elements) in WXS.
Verbosity has long been my biggest problem with namespaces as currently implemented (and yes, xlink is a perfect example of that). I think a lot of people are thinking now about scoping or umbrella variables, and this "crisis" may very well be the catalyst for that.
Okay, you've triggered a rant. Those of you who are partisans of the
Namespaces in XML Specification are hereby warned: the following will
annoy you. I'm going to be offensive (although more offensive to the
W3C folks who forced URIs onto the Working Group than to the Working
Group members themselves).
...
The insistence of the W3C on URIs (that aren't, in fact, URIs) as
namespace identifiers is, to my mind, the worst thing that could have
happened to XML. Because the URI specifications are not in the control
of W3C, and the BNF for URI (however widely ignored in detail) cannot
drop multiple characters otherwise illegal in XML element names, the
Namespaces in XML specification was forced to introduce
namespace-to-prefix mappings, and the subsequent use of prefixes in
element and attribute content poisoned the well completely. James
Clark's (brilliant) suggestion for expanded names, {uri}localname,
simply never saw adequate adoption (in part, perhaps, because W3C XML
Schema defined anyURI and NCName and QName, but not ExpName (or JCName
:-)).
Wow! Okay, I definitely agree with the crux of the rant.
There are times I feel we don't have enough meta-characters. The biggest problem with {uri}localname was the role that angle brackets play in both XSLT and later XQuery. I've often thought that [uri]localname works better though, both because there are considerably fewer collisions for square brackets in XML processing languages and because it's become something of a convention in email: "[xml-dev] This is my title" has a natural, intuitive feel. It also makes <[org.w3.xsl.transform]stylesheet> feel similarly intuitive and somewhat easier to read than most of the other schemes I've seen.
While the XML 1.0 specification is (a thing of beauty and a joy
forever) one that I point out to others (whenever I am engaged in that
horrible perversion, specificating, in company :-), the best that I can
say for Namespaces in XML is "well, yes, that's clear enough; it can be
implemented." Whoever forced URIs on the working group--very likely
TimBL or Roy Fielding or their disciples--did them a disservice. XML
namespace identifiers do not need that generality, and should have
chosen a representation that allowed compact (but unique, with
distributed authority) indication within an element name. Perhaps,
rather than the dotted-on pattern that Micah has proposed, they could
have made "qualified names" use colons in place of dots in domain names
and in place of slashes in paths (com:w3:org:1999:xlink:link). Still
verbose (Micah's "using" syntax is rather ... nice), but not as painful
as NiXML.
I think the dot notation has an incredible degree of merit ... the use of dot-notation has become standardized as a representation of class and package hierarchies in most languages, and I suspect that its use in XML would go at least a part of the way of assuaging the large number of JavaScript programmers that XML isn't really evil. I'd also point to e4X notation (as well as Linq, which follows a similar format) as a way of specifying child notation.
The biggest argument against the adoption of XML in HTML has generally been the cumbersome DOM interfaces, which I've brought up before. They served their purpose back in the early days, but in the process of trying to develop generalized APIs, somewhere along the line simplicity got lost. The namespace problem is a direct artifact of that.
I agree that this is fundamental, and also worry (though I'm not
familiar with HTML 5 or WHATWG people sufficiently to judge) that the
intent of HTML 5's restriction of permitted namespaces is for the
purpose of controlling (that is, limiting) extensibility.
> The language NEEDS an extension mechanism.
> The language NEEDS an extension mechanism.
> The language NEEDS an extension mechanism.
You won't mind if I quote this multiple times, will you? I can't think
of a better way to indicate how much importance I accord to it.
> The language NEEDS an extension mechanism.
> The language NEEDS an extension mechanism.
> The language NEEDS an extension mechanism.
Heh!! I don't think this is important enough to you ;-)
I really, really wish that someone from the HTML 5 working group would
come forward with an indication of what, in the WG's opinion, the fatal
flaws of XML namespaces are. I can guess at a number of them (the fact
that many, many people new to XML cannot understand that elements are
scoped by the schema (and namespace-qualified) while attributes are
scoped by the element (and hence unqualified) by default is one;
verbosity, incomprehensibility ... well, I'm not a big fan of
Namespaces in XML apart from the rather insipid encomium, "yes, that
can be implemented"), but ... I'd like to see HTML 5's "non-XML" syntax
permit a lossless transformation into the XML syntax and back. It
doesn't need *XML* namespaces to do that, but it does need ...
something with the good qualities of Namespaces in XML.
Yup.
> chooses to cede this point, then for all intents and purposes the XML
> movement is dead.
Oh ... I can't really agree with that. I mean, I saw that the HTML 5
working group was defined *in terms of the DOM* and Boggled and Fell
Down. Does anyone who does XML for a living have any respect for the
DOM APIs? And yet ... it's clear that those are core to the browser
experience (which is why they suck so hard for any other usage, in my
opinion), so it's really perfectly reasonable that the browser folks
should start from the DOM. In any other application of XML, a mutable
tree API is at best a dead weight, but in the browser, it has
utility--utility to the point of necessity.
Let me explain my argument here. In an ideal world,
Bifurcation? Certainly. HTML could become a non-XML dialect. I'd
hate that, but it looks as though there's at least a part of the HTML 5
working group who would welcome it. Killing XML? Nah. The HTML 5
working group can miss an opportunity (and it seems likely that they
will), but distancing HTML from XML won't kill either one, it will just
annoy the folks who have to develop the techniques to reconcile them.
Do you ever feel like putting your fist through a window just so you
can feel something?
