The XML 2007 Conference has come and gone, with as usual a number of thought provoking talks and controversies. During the evening of the first day, there was a special XForms Evening, with a number of the industry gurus in that space providing very good examples of why XForms is a compelling technology and here to stay.
In the final keynote session, though, Elliott Rusty Harold sounded a somewhat more alarming note, indicating that while XForms does have a huge potential, there are no killer apps out there for it, and without significant support from the various players in this space it will be dead within the year.
Now, I need to say up front that I have a huge degree of respect for Elliott. His blog, Cafe Con Leche (www.cafeconleche.org) is one that I read regularly (and recommend highly), and he generally has his fingers firmly on the pulse of the XML sector in a way that few others do. I think in this case that he is right. There are no killer apps for XForms right now, and without significant industry support, the standard will be dead. However, what I think he gets wrong here is that for most XML technologies, that has always been true, and that it has not hampered the adoption of XML-based technology much at all.
How many XML developers are out there? I suspect that the actual number of people who are like me, who tend to work almost exclusively with the XML idiom, is fairly small - a few thousand people perhaps. Small enough that I still know the names of a lot of them, and have actually met a significant share of the programmers in that space. Now compare that to C++ or C# or Java, or even PHP or Ruby. The number of C++ developers out there rather beggars the imagination - if XML is a small, sleepy town, C++ is a fairly large metropolis, a couple of million programmers at any rate, though I suspect that somewhere in the last half-decade Java slipped ahead of it for sheer size.
However, this self-identification exercise changes considerably when you ask the question in a different way. Rather than asking “Are you an XML developer?”, if you ask the question “Do you use XML in some aspect of your work?” the picture looks rather astonishingly different. SOAP, RSS, configuration files, data and content production and management, web development and deployment, application development … I’ve just begun to touch on the number of areas where XML figures in some capacity, and my gut feeling is that this penetration of XML into other spaces will only continue unabated for several years yet.
This is generally not true for most imperative media. PHP programmers generally try to avoid Java, and only write C++ when there is no real alternative. C# developers seldom drop into C++ within the same projects, though they may switch batch and forth between the two, but you also seldom see C++ devs soiling their hands dealing with Java (and vice versa). In other words, while there are a few exceptions, the intersection of most imperative languages with other imperative languages is usually quite small.
XML is a cross-cutting language, and its associated technologies go across other language silos as well. I can run an XSLT 1.0 transformation in nearly any language out there, including languages such as Haskell that are far from the main stream. I can generally parse a DOM everywhere. My suspicion is that within half a decade I should be able to query data via an XQuery call in just about any language. SVG has taken some significant hits in the last few years, yet it continues to fight back, like the battered hero in all too many adventure films that looks to be down for the count, sees the woman he’s fighting for, then steps up and delivers the knockout blow to his opponents.
So what about XForms? Where are the huge legion of XForms developers, the multi-billion dollar IPOs, the twenty columns of XForms ads in the help wanted section? Where are the killer apps?
A great deal has been made out about Microsoft’s intransigence in this space, that somehow if Microsoft decided tomorrow to pour in millions of dollars in research that XForms will suddenly become a real application that not only developers but analysts and investors would start to take seriously. It ain’t gonna happen … at least not for a while, any more than SVG is going to start appearing natively in Internet Explorer. Microsoft’s goal is to take back the web, to regain that market monopoly that they held until recently, and they see W3C technologies in general as being anathema to that strategy. The same can be said to be true for Adobe and others with established interests in the forms space.
Yet curiously enough, you can get XForms in IE, and have been able to for some time. You can get it on a lot of different platforms. One XForms “player” is written in Flash, and takes advantage of a number of the Flash platform, while others are plugins to existing browsers or are embedded into mobile players. The budgets for most of these efforts could easily fit into the cost of a single Microsoft print ad, but they exist nonetheless. In that sense, XForms is in fact following in the footsteps of nearly every major XML technology that has come from the W3C, OASIS or other XML-centric standards bodies.
Is XSLT successful? Actually, yes, it is, even though you don’t see calls for lots of dedicated XSLT developers. Indeed, I’m not sure why you would, except perhaps in the space of content management. XSLT is a specialized tool, useful when needed but otherwise kept in the toolbox. Increasingly people can count on it just being there in the toolbox when needed. It has no conferences or seminars where people pay thousands of dollars to get the news of what features they can expect to finally end up with in their framework of choice. There are no companies taking out big two page spreads in Wired promoting their latest XSLT processors … yet like much of the technologies upon which the web is based its becoming infrastructure nonetheless.
I believe XForms is following this same path. Pundits will continue declaring its imminent demise, year after year, and yet, year after year, it’ll end up on more servers, more desktops, more browsers and mobile devices. XQuery + XForms is proving to be an incredible “sell-point” that a number of independent developers are stumbling upon as a potent combination, and as XQuery continues its own definite upward trajectory, I suspect XForms will come along for the ride.
Thus, my anticipation is that the number of XForms specialists will remain comparatively small for some time to come, but they will be educating others, who will quietly be incorporating XForms as a way of life into their applications. Some (many) of those will come from the AJAX community, both as AJAX implementations of XForms continue to proliferate and as many who work at the intersection of AJAX and XML understand that while they CAN continue to rebuild the wheel with every app, they can get a lot farther with XForms as part of their toolkit. Some will come from the Flash world, as they discover that if they start thinking in terms of MVC driven architectures it makes it easier to build data-centric applications, and the XForms toolkit provides a good foundation for building on that. A few (a very few, I suspect) will make the jump from imperative languages - the chasm to comprehension is probably too big to bridge unless you’ve already dealt heavily with XML technologies.
Similarly, I think that you need to make a distinction here between “the industry” and a few companies such as Microsoft or Adobe. There are actually a number of vendors in this space that are doing quite well thank you, especially as interest in large XML vocabularies such as XBRL, HL7 and other vertical efforts continue to rise. IBM’s Workplace forms incorporates XForms, as Sun had done with OpenOffice, Firefox has had XForms support ongoing for nearly two years, and products such as Orbeon, Formsplayer and Picoforms have continued to gain adherents. XForms support in desktop browsers is moving slowly, unfortunately, a space where more innovation needs to happen, but at the same time support DOES exist in one form or another, even if such support is not always native.
On the flip-side, part of the change is also coming from the XForms working group, as they realize that while it is POSSIBLE to create a stand-alone application layer in XML, its not necessarily desirable to keep everything constrained to that one layer. Changes that are making their way in XForms 1.1 indicate the recognition of this fact, though there’s also the tacit awareness that IF you can encode at least some of your business logic in terms of REST or SOAP-oriented web services, this restriction becomes less of a factor. Incorporating XPath 2.0 as a target path representation would go a long way towards this goal as well, as would integration between XForms and XQuery, but I see these as discussions for a few years hence.
XForms has gone through both the top of the hype cycle and the trough, and while perhaps a little bedraggled and waterlogged, has managed to make its way to the other side where the real main-stream adoption occues. I’ve been tracking XForms news for some time, and I find it significant that, after having all but disappeared from the scene, XForms awareness is growing at a pretty nice clip again.
There are two quotes I want to end this column with, both on the nature of making things happen:
It is amazing what you can accomplish if you do not care who gets the credit.
Harry S Truman (1884 - 1972)>
Never doubt that a small, group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.
Margaret Mead (1901 - 1978)>
XForms is in no danger of fading away.
Kurt Cagle is a writer and programmer who lives in Victoria, British Columbia, where he sits drinking coffee and watching the winter snow fall.