+2 on DOM
DOM was necessary at the time - you needed a way for external languages to have low level access to XML in order to create tools (such as XPath, XQuery, E4X, etc.) that provided higher level accessibility. The problem was that rather than build XPath or E4X like layers into the browsers, the browser implementers took the DOM spec as the baseline for working with XML, and it took years for any kind of advanced technology to work its way into even a few of the systems (and that often badly). Trying to invoke an XPath statement and do anything useful in Mozilla is hideously painful, even though it would have taken remarkably little effort to make it more usable. E4X (or at a very minimum the creation of XML objects as transparent entities that can be queried via a path language) would have gone a long way to solving that, but there was very little push to get behind it within the W3C, because it was seen as an ECMAScript issue.
About namespaces - people moan and complain about namespaces, but the biggest problem with them overall was that there were two schools of thought with regard to namespaces within the XML community. The first saw namespaces as a way of applying a class-like semantic to a closed but potentially mixed ontology; this is actually most evident in languages such as XQuery where you have modules that contain functions, which provides an (rough) analog to classes and methods within an OOP environment. The second saw namespaces as a way of identifying authorities, and I believe this is where namespaces largely failed. Anyone who has pored through NIEM or XBRL records understands how confusing such authority layers can be, even by people who otherwise understand the specifications themselves. We've had discussions on this particular forum before about alternatives to namespaces (with some remarkably good ideas being proposed) but rather than actually pushing the changes into some kind of action in most cases these ideas ended up becoming simple gripe sessions.
Which to me points to the bigger problem - process. AJAX came about because a lot of people threw a lot of ideas around, kept the ones that worked, and dropped the ones that didn't. XML on the other hand established apriori specifications through long and involved processes, typically with comparatively little input from the developer community, and often shooting for broad generalized solutions rather than creating things from scratch and then seeing how they could fit into the XML community overall. Significantly, if you look at the most important "standards" in the W3C canon, the ones that had the biggest staying power usually were produced by one person and then "smoothed out". XPath (James Clark), XSLT 1 (James Clark) and 2 (Michael Kay) falls into that category, as does RNG (James Clark again), Schematron (Rick Jelliffe), XProc (Norm Walsh), XForms (Mark Birbeck and Micah Dubinko), XQuery (Michael Kay), RDFa (Michael Birbeck) and the like. That's not to say that other people didn't contribute significantly to those specs, but it was usually the reference implementer that was defining the characteristics of the specification in the first place.
Look at the specs that people typically complain most heavily about - XSD, Namespaces, SOAP and the WSDL stack, SVG (good idea, but one that succumbed quickly to corporate dominance), XML-RDF, as well as some downright obscure ones like SML (the Services Markup Language), and of course, the brilliantly failed XHTML/WICD concepts, which got bulldozed out of existence by Ian Hixon who recognized that modular XHTML was a good case of XML jumping the shark. All of these were specs that came either came into existence or were quickly taken over by large committees representing corporations with strong vested interests, and with no single champions strong enough to fend off those interests in the name of communal standardization. They became catch-alls for a couple of key corporate players with strong agendas (SVG and Adobe is a prime example) that were looking at creating a "specification" that they would have a strong lead in upon completion. SVG is finally gaining traction universally, and curiously enough, most of that traction has come about in the non-animating portion, because that represented what was really needed in most cases.
I think the danger that we face at this juncture is throwing out the good with the bad. XML has gained adoption not because of the XML standards community. It gained adoption because it filled a very definite niche - document-centric structures - quite well, and over time more and more "data" is being represented this way because data is becoming more robust and document-like. That's not going to go away because the browser community (which I see as becoming a decreasingly important part of the overall equation as mobile devices become the norm) has decided that everyone needs to be AJAX developers. It does, however, mean that the XML standards community needs to understand that it has to reach out and recognize that the infoset can have multiple serializations, that not all those serializations are going to involve angle brackets, and that collections of content ultimately will end up becoming more important than individual documents.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
On Tue, Nov 30, 2010 at 8:21 PM, Liam R E Quin
<liam@w3.org> wrote:
On Tue, 2010-11-30 at 19:59 -0500, Elliotte Rusty Harold wrote:
> On Tue, Nov 30, 2010 at 6:47 PM, Amelia A Lewis <
amyzing@talsever.com> wrote:
>
> > I'm increasingly of the opinion that XML "jumped the shark" with the
> > XML Namespaces specification.
>
> Namespaces was at least the nose of the shark. I think we really
> should have insisted that prefixes not be able to be bound to more
> than one URI in the same document.
particular restriction would be helpful, because it would complicate
reuse of document fragments. But, lack of consensus at the time
reflected lack of implementation experience -- namespaces should have
been put on hold for a couple of years at least.
> Schemas are bad, but ignorable.
I think XSD has some OK parts, and, like namespaces, meets some real
needs... while causing lots of problems of its own.
>
> I remain convinced, though, that the single biggest mistake was DOM.
+1 here, totally agree.
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
