The More Things Change
September 14, 2005
Editor's Note: In this column, Micah Dubinko concludes XML.com's longest running column, XML-Deviant, by looking back at how things have changed and how they've stayed the same. It's time for XML.com to evolve, now that the classic era of core XML specifications is ending. Part of that evolution includes saying goodbye to an old, valued friend so that room can be made for something new. Dubinko is working on some new column ideas and will return next month.
A lot of staying on top of XML is just keeping up with two kinds of things: those that change, and those that stay the same. Plenty of both can be found on the xml-dev mailing list and other discussions within the community. This week, XML-Deviant takes a retrospective look back as far as the column's origin, January 2000 -- about two years after XML was finalized, and about one year after XML Namespaces was finalized. As we will see, although plenty has changed, likewise plenty has remained constant. Discussions continuing to this day have echoes reaching far back.
Identifying things that can change is a classic design problem. For example, designing an XML vocabulary involves committing to certain things like specific element names, while allowing for variability in all the right places. Over time, certain design patterns come to be known as best practices while others remain, shall we say, debatable. Of course, the flip side of best practices is made up of things that are, to borrow a phrase from Robin Berjon, "signposts of pain."
Ghosts of Schema Past
The topic was Web 2.0, the contemporary mix of technology and attitude, when an off-the-cuff respondent asked, "Anyone up for voting out XML Schema in favor of RelaxNG?" Among the responses was the signposts phrase; in turn a more serious response came from Mike Champion.
My strawman list would start with: trying to do too much at once with a single spec. There's some famous quote along the lines of "all successful complex applications were once successful simple applications" that we should all probably ponder daily.
Some thoughtful analysis also came from Dare Obasanjo and Robin Berjon.
Going back though past issues of this column is almost painful, observing the formation of XSD as we know it today. For example the first ever XML-Deviant noted "that the xsi:schemaLocation attribute serves as a hint," making it almost worthless in the long run. By the summer of 2000, the Schema documents were in Last Call, with the expected anguish about how to respond to the call for comments. Weeks after Schema went final, XML-Deviant had more coverage of pain, not to mention opening old wounds a few months later.
Not changed: brutal criticism of the W3C, especially XML Schema.
Changed: later Working Groups, while still building on the complexities of XML Schema, seem to be avoiding several of the major pitfalls. Perhaps reflecting a loss of credibility, though, wide-scale initiatives like Web 2.0 play less by W3C rules.
Ghosts of Namespace Past
Volumes could be (and have been) written about all the various criticisms leveled against XML Namespaces. That topic threatened to reignite recently, as Alan Gutierrez asked, "Please point me to a discussion or article that will illustrate the flaws in Namespaces."
Happy to oblige: there's Namespace Trouble, recounting the good times that resulted from relative URIs in namespaces -- with commentary from the anonymous Pope 32767. There's all the discussion about what, if anything, should exist at the far end of a Namespace URI. One more and I'll quit here -- my personal favorite: How do I hate thee?
Not changed: Namespaces still provide a seemingly endless pit of despair and confusion for developers.
Changed: despite that, developers are getting on with life, accepting the inevitable. Namespace threads on xml-dev have gotten much shorter.
Objects and Binary XML Permathread
A mailing list like xml-dev is inhabited mainly by programmers, which can at times lead to a, well, focused viewpoint on things. A quick show of hands indicates that nearly every coder has at some point crafted a text-based data representation language of some sort. Yet the whole theory behind XML was to replace much of the ad-hocosity with a single standard. Against that backdrop, Mike Champion notes, "the world seems to be going in several directions at once with respect to the relationship between programming language objects and XML." He goes on to hint at some developments at both W3C and Microsoft, then observes:
I'm not sure what to make of all this, other than that there is a lot of dissatisfaction with the status quo with respect to XML and programming, and a lot of experimentation going on to address it. Some approaches might threaten XML's story as a universal data interchange format, or might revitalize it by scraping off the cruft, we shall see.
As you'd expect, these pages have covered alternatives to XML, especially around the W3C workshop on the topic. As far back as 2001, the discussion was described as "a well-loved debate." Even my very first installment here delved into this self-same topic.
Not changed: for solving general problems, XML continues to be the worst possible technology, except for everything else. Experimentation and complaining abound.
Changed: the W3C now has a Working Group which says that Binary XML is necessary, feasible, and that a single solution could serve everybody's needs.
Not changed: nobody's paying attention to the W3C's grander proclamations.
|
|
|
Also in XML-Deviant |
|
What Now?
Are we going in circles? Or just covering the same ground and hashing over the same tired arguments? The answer is, of course, yes, though in a good way. Get a few geeks in the same room (or often, just two) and you've got all the fixin's for a lively debate. Despite what seems at times like bickering, xml-dev provides a useful forum that has helped to shape the opinions of many readers. Thoughtful commentary regularly shows up from those in the best position to render a valuable opinion.
The list also provides a useful consensus monitor. Is xml:id a good thing? Is
binary XML a good thing? What's wrong with Namespaces anyway? When a rough consensus
exists,
it surfaces eventually. When no consensus exists -- when multiple outlooks are both
possible
and strongly defensible -- well, that's where the permathreads come from.
In any event, the mailing list continues to be a useful resource with no signs of slowing down.
Not changed: xml-dev, we still love you.