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.
Indeed, when you stop and think about it, you might begin to realize how very unusual XForms is in that regard. It’s an application layer that transcends the implementation it is written in. It doesn’t matter whether I’m writing an XForms component in C++ or Java or XUL or JavaScript - what is important is that I can send run the same “applications” on any system, that the ecosystem is fitting XForms in where it can, despite the very best efforts of certain vendors to kill it.
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.
Hi,
I am not Xml Developer but is interested in making use of it considering its huge recognition base. But I do have one doubt
if in type of application I am working on, Is Xml a suitable choice, from performance point of view.
I am developing a client-server application. I have thought of an architecture where client generates the request and keepts in Xml format somewhere in the network and intimates server to read the request. While I have tested the application, I am wondering if would have used network -sockets to pass the complete request details to server, would the appliction had performed better? Can someone guide me on this.
A killer app can give a push and you just need a topic with great concern. Such a topic can be genealogy and XForms can be a great tool to handle this since XSLT is able to work on text files. Most people still use the old gedcom text files although the latest gedcom version was one of the first standards using xml. The group of gedcom users is huge enough to contain people that learn XForms and spread it. The most will simply ask for things like Prism or Sidewinder, if they support XForms and XSLT 2.0 and IE doesn't. This is just an idea, but I'm not a developer.
I don't know if I agree with Kurt. To me, you'd only use XForms if the data structures that composed your data model were built in XML. I think the largest benefit of using XForms is that you can modify your data model directly, instead of having to compose it from the parameters of a form post. In fact, if my data model weren't composed in XML, I'd find using XForms more of a hassle, because transforming an XML document into classes (supposing I'm using Java) would be WAY more of a pain than using a standard form post.
I agree with Elliott. I think if XForms is to survive some killer app needs to be developed. XForms makes editing XML documents easier, so IMHO it's XML that needs the killer app. Usage of XML needs to skyrocket, then XForms will do just fine.
One idea I had recently was along the lines of Amazon's SimpleDB. I can only think of a few really good uses for SimpleDB. However if SimpleDB allowed me to create collections, dump XML documents in them, and query them with XQuery, I think we'd see the usage of XML skyrocket. There would be semantic web projects popping up all over the place -- all that used XForms to edit content. I don't know if building that kind of app would scale in the way that I'm sure SimpleDB does, but it would be interesting to see.
One of the things I've been watching for some time is the dichotomization between the popular and enterprise spaces in terms of XML technology adoption. XML has become very pervasive in most enterprise applications, to the extent that it has begun shifting the balance in terms of how both data and documents are stored in that space - and one of the questions that keeps coming back to me is one of how to get that XML into the web portals and communicating with web clients.
A significant portion of the "popular" space, on the other hand, has been built on mySQL/PHP, and PHP in particular has only just recently reached a point where they had a decent XML parser to speaker (based on libXML), so as a consequence, XML plays a considerably smaller role there.
My expectation is that over time, pressure is going to build in the system to "pipeline" data content (I'll address this in a post here shortly). SQL has no clear syndication strategy - records are returned as text which has to be parsed according to sized fields and then output into the object du jour, which in general is neither standard nor readily persistable across the wires.
I can really see only two formats that might even come close to such a messaging format - XML and JSON. JSON's popular among Javascript programmers because its the "native" format - there's relatively little cost incurred to parse or serialize it, but JSON lacks both XML's flexibility (it's a poor document format, for a number of reasons) and it also incurs a larger overhead with other systems, especially those that have poor reflection stories.
Expect to see more of XML making its way to the client, and keep your eyes peeled beyond just the browser in that regard. In the mobile space, XML is already the standard protocol of choice, and for an increasing number of browser-lite apps - web enabled clients that are not necessarily themselves browsers or based upon browsers, this holds true as well.
Kurt,
Thanks for another great article on XForms. I agree with your point of view. XForms has a bright future. In our consulting practice in different companies, we see a lot of very painful problems that XForms can fix easily. What it takes is developers and architects who can step out of their comfort zone and experiment with new ideas. Most importantly, it takes technical leadership that encourages and rewards that attitude.
Joel Amoussou
Efasoft
>In fact, if my data model weren't composed in XML, I'd find using XForms more of a hassle, because transforming an XML document into classes (supposing I'm using Java) would be WAY more of a pain than using a standard form post.
Two points...
1. Using a standard form post (HTML 4 Forms) means your model (Java class) isn't available in your form. So you can't write any dynamic behavior using model-based programming, unless you refresh the entire page on each interaction (not totally ridiculous, but a bit old fashioned).
2. Java classes XML is very easy using JAXB & annotations.
I don't believe that a 'killer app' is the issue regarding the life expectancy of XForms. It is the realisation that declarative programming is the 'killer app' for the web. When people wake-up to what can be achieved using XForms' bindings, model item properties and XPath; whole swathes of client-side scripts will be swept away. In addition, once you have captured the logic within your XForms enable web application the principles are immediately re-usable in other projects without having to right a whole new set of code to support the same types of rules.
The same applies to presentation of content and user-interaction. The depressing lack of interest in the SMIL Animation module is another example of how declarative programming has been under-valued. Most people will have only encountered it through SVG but it is a standalone module in it's own right, and as such could be used in XHTML. My experiences with SVG, Mutation Events and SMIL Animation suggest, like with XForms, that you can say goodbye to piles of tedious client-side scripts, the endless reinvention of JavaScript libraries that all do the same thing anyway and look forward to a future where you declare what you want to happen and the client does it for you.
This is not to say that JavaScript is history, not by a long chalk, but declarative programming is much better at doing the everyday stuff like sticking in a constraint here, defining what part of the content should appear when I click there; and when XML Events 2 steps into the picture the more specialised behaviours that require scripting can be hooked into the events mechanism in a declarative way too.
Don't think about any one technology and then look around for an application to build instances of it. Is there a JavaScript 'killer app'? No, I don't so. There are editors with useful code features that people use to make JavaScript work for them. You can edit XForms in an editor and editors may have useful XML editing features. What people must do is look at what it means to use a technology and how it can change their way of thinking and working. That way, the technologies have the potential to sell themselves by example.
So, bring on the implementations of SMIL Animation, XML Events, DIAL and XForms and lets free ourselves from the shackles of client-side scripting and cross-browser support.