Adriaan de Jonge’s article Xforms vs. Ruby on Rails has created quite a stir in both the XML and Ruby communities, and for good reason. He asked a fairly important question - are XForms an also-ran technology that Ruby has managed to supplant?

I’ve been thinking about the article for some time myself. Certainly it’s a difficult question to answer, because to a certain extent I tend to agree with him … on some aspects. XForms had a lot of potential that it hasn’t yet lived up to, does require more than a little bit of advanced computing skills (or at least the right mindset) and suffers the fate of many of the W3C standards, which is to be smashed up against the rocks of browser vendor indifference.

And yet … I’m not quite ready to throw in the towel. Now, don’t get me wrong. I’ve worked with Ruby, and overall I think it is a delightful language for many of the same reasons that Adriaan does - it is more declarative than imperative, it places unit test planning well ahead of coding, it fits in very nicely with the web development paradigm, and it works reasonably well in mapping basic data sources into objects. It’s contributions to the development of JavaScript have been crucial to the success of AJAX, and overall I think that it would not be a bad skill for any web developer to have on his or her resume.

My quibble with the argument is that to me Ruby is an apple, XForms an orange - or perhaps more accurately, Ruby is a framework, XForms is a systems component. This is true whether XForms is supported by a server framework (such as Orbeon), is a standalone client component (such as the Mozilla XForms) or FormsPlayer, or is a JavaScript overlay (such as FormsFaces or Chiba). In all of these cases, there is a minimal assumption made about the server - that it will, in some fashion - provide to an XForm one or more XML data models to work with, and will know what to do once the XForm sends the data back on its merry way to the server.

Componentization is a very key part of SOA, and to a certain extent represents a fairly radical shift away from the web development paradigms of the past, but determining the when and where of that componentization is one of the very real challenges facing methodologists and architects. One school of thought is that such componentization should occur at the widget level. ASP.NET follows this model, as to a great extend does Ruby. The idea here is that your widget components should talk to directly to the server out of the box, so that a web page is in fact a whole collection of little transmitters and receivers, each of which holds its own internal data-model that’s largely irrelevant to everything else on the page.

Now, this isn’t a bad idea, as far as it goes, but it has some interesting implications - first of all, you still end up with a fair amount of loose scripting going on with the client in order to tie components together, and in my experience, trade show demos not-withstanding, most web applications usually involve the process of having multiple components on a page communicating with one another. In other words, you still need to get into the code to handle those bindings, now matter how fast or fancy the widgets.

Another way of putting this is that regardless of whether you are working with XForms or Ruby or ASP.NET, your data models are likely to be considerably more complex than a single stream of static XML. Modeling that data flow is in many ways as important as unit testing is, and it is, interestingly enough, one of the things that XForms is actually quite good for, as you need to specifically understand that data model explicitly before anything will show up on the page.

The XForms architecture pushes the level of abstraction up a level. In this case, the components that you interact with on the page are not actually involved in maintaining the data model - only in changing it. This is a subtle distinction, but an important one. In an XForm, I create one or more models and associated instances (though more typically I import these from external resources). The models are there regardless of whether there is a single component on the page. I can change some aspect of the model through the interface widgets of course, but these widgets are communicating directly with this local reflection of the data model rather than being responsible for their own internal data states.

This is actually a pretty profound expression of Model/View/Controller architecture. The model is centralized, true, but its centralized locally (and even this isn’t completely true, as you can have multiple extant models in the same XForm). You can keep the model the same and completely change the components, dynamically and in real time, and it won’t change the state of the page. The face of the application is made up of components, but you can readily have multiple faces. In other words, what XForms does is turn the particular page itself into a SOA component, one that can provide an abstraction between the server and the client through the data model.

Compare this to Ruby, which tends to have a one size fits all approach to component development where you don’t have a great deal of latitude to do customizations unless you’re seriously prepared to roll up your shirtsleeves and work. Sure, one solution to this approach is to build lots of components, but that component library in term opens up issues of incompatibility, differing programming styles, varying levels of quality and support issues that proves to be one of the biggest reasons why Ruby overall is not being embraced quickly by enterprise level developers.

This brings up a second issue, though again its an apples vs. oranges comparison. XForms is useless for a fair number of web development tasks. If you have a fairly simple form (perhaps four or five fields), XForms adds a fair amount of overhead to the tasks of parsing through that small number of properties, and provides only minimal value there. Without tweaking the language somewhat, (such as recognizing the possibility of rich text (XHTML or other XML languages) input and output), XForms wouldn’t be my first choice for a rich editing system (though with those tweaks I probably would).

In other words, XForms is at best a novelty on (most) consumer facing sights, at least for now, because in most cases, the MySpace crowd is likely to be only marginally interested in working with sophisticated form-like applications. Consider that to a certain extent this was also an issue with Visual Basic - while there were a fair number of VB applications out there that people could download and work with, for many years VB’s primary market was at the enterprise (from the SOHO market all the way up to megacorporations). Is this a failing of the technology? No, of course not - its a realization that XForms applications are most likely going to be utilized precisely in those areas where Ruby won’t be.

Where XForms comes into its own is when you’re dealing with data - lots and lots of data. The beauty of most XForms applications is that they are in fact quite customizable, usually without a huge amount of work, but that they recognize that data is complex - multilayered, having complicated interdependencies, conditional, and frequently transient. Most of the clients that I deal with when building XForms applications are not, in fact, looking at building another community site. They are health authorities, school district administrators, community services providers, companies looking for ways to come at their data in different ways without locking themselves into one and only one view.

Here’s an interesting observation here too - I personally think that the days of shrink-wrapped software are history, and the days where you could build another salesforce.com are fading. My own dot-com experiences have generally been pretty negative, because what I saw all too often were people who were more entranced by making a cool widget or indispensible service to the countless millions of people, and generally failing. Increasingly, software is becoming oriented towards helping people with lots and lots of data get at that data more effectively.

My third counterpoint actually echoes the first. XForms is not a whole solution. It actually works better in conjunction with something else, which I am increasingly coming to believe is an web-enabled XML database working with either XQuery or XSLT (preferably both). Frankly, while I have my favorites (and will be profiling one of them, eXist, in an upcoming article) what I’m seeing is that outside of a fairly narrow space, again centered primarily around social networking, XML has become THE language of data transfer. This is not to say that I think that native XML databases will take over the world - I don’t, though I think the market for them is good - but only that as serialization formats go, XML is pretty much a given, and if you can provide a publishing API around your XML providers/consumer, so much the better.

But what about JSON? JSON and Ruby on Rails are fairly closely tied together, and from the metrics that I’ve seen JSON has perhaps thirty percent more efficient for small to mid-sized data, especially when parsing. It also works conveniently with JavaScript code (thus the ties)., and more closely resembles the way that procedural developers work with their own data structures.

Yet JSON is not going to seriously jeopardize XML in the enterprise space. It is not as expressive, cannot readily embed document content without relying upon some form of HTML or XHTML markup (which right there significantly weakens the parsing argument), requires a fairly complex markup for schema validation (or blithely ignores that one might in fact be needed), places a fairly heavy overhead consequently upon placing semantic markers within data streams, and doesn’t readily handling scaling. This is not to denigrate its use - I use JSON myself, and think there are places where it works quite well, but I think that in order for JSON to become as widely used as XML, it will end up looking so much like XML (with many of the same attendant problems) that it will likely prove to be just yet another markup language.

Thus, if you recognize that XML is increasingly becoming the mechanism used to transport data between points in the network, if you assume that we’re moving towards a final working solution with web applications somewhere between REST and the SOAP/WSDL duality, then the idea that you need a client or light server application that is conversant with XML only makes sense. Ruby has some interesting XML capabilities, admittedly, but you are still dealing with working outside of the XML abstraction with Ruby, whereas in an XQuery/XForms/XSLT solution, you are quite literally floating in an XML sea, where XML coming from a collection or external server is only a function call away.

Ease of learning. Okay, I’ll concede that one. XSLT is non-trivial to learn, XQuery is only marginally easier, both because you’re having to think in a declarative mode at a level of abstraction beyond C++ or Java. Yet most colleges are teaching courses in XML (and some in “advanced” topics such as XSLT), whereas Ruby is being picked up largely as a cool language by some generally advanced web developers who have been fighting with the bone-headed paradigms coming from server-side vendors for years and not really quite sure why, but there are few colleges that are making career tracks out of Ruby (or even AJAX, though I think that’s a combination of funding and the time that AJAX has been out). Ruby on Rails will be an attractive solution for a lot of web developers, but its not, in my own opinion, going to make serious inroads against PHP on the one hand or ASP.NET on the other.

XForms, on the other hand, doesn’t have to. XForms is about to go native on Mozilla Firefox (my guess is an optional part of the install once things move far enough along on the extension), and XForms based solutions (in JavaScript in many cases) are making XForms on IE a reality already. This means that XForms can work with PHP, with ASP.NET, with JSPs, in short with any server platform out there … including Ruby.

It’s worth understanding that the ultimate goal of XForms is to provide a consistent mechanism for creating XML on the client to pass back to the server, and for displaying XML content from the server in a reasonable “face” that’s responsive to changes in the underlying data model. That’s it. XForms doesn’t create graphics (though it can be used for this), it doesn’t make for pretty animations (though it can), it doesn’t handle drag and drop (though there’s no reason it can’t be used in conjunction with something that does). It’s got a nice extensibility story in many cases, typically through CSS or XBL or some similar binding language.

Ruby’s Here, XForm’s Not. A good argument, and one that frequently trumps all others. However, its not really that true in this case. XForms is being used all over the place, just that most of those places are not necessarily the ones that the average web developer is privy to. Google XForms and health care - half a million entries. XForms and Insurance - 453,000. xforms and the military - 648,000 hits. A lot of ink has been spilled about Ruby on Rails, because the Internet most loves to talk about itself, but the reality is that, despite all of the problems that its taken for the XForms community to get past the wall of browser indifference, XForms has taken off in those places where it’s most suited, and this even before there’s a native version of XForms sitting in a browser.

XForms has been a long time coming, in part because its been held hostage to interdependencies with other W3C standards, in part because it is a solution that was originally intended for the web browser client that emerged when Internet Explorer had a lock on that space. I encountered XForms several years ago and came away thinking that while it was an interesting spec, in a world where SQL and IE ruled it wasn’t going to go anywhere, not then. Not then. However, it’s back, at a time when companies are beginning to recognize that SOA is more than simply having a website, where several companies and open source projects are now actively pushing XForms solutions into everything from browsers to hardware.

I’d say that, before dismissing XForms in favor of Ruby on Rails (or any other browser technology) ask yourself how much XForms could potentially improve Ruby, how much it would simplify the XML side of the equation. Just as XSLT is not the ultimate web solution but nonetheless is a major tool in nearly every server platform, I see XForms becoming a common (and compelling) starting point for building a similarly useful tool on the client. It’s all too easy to create false dichotomies in programming, but this one in particular doesn’t need to be. I’d far more like to see XForms and Ruby on Rails rather than XForms vs. Ruby … and I suspect so would your customers.

Kurt Cagle is a writer and consulting specializing in AJAX, XML and web 2.0 technologies, and is the administrator for both the XForms News Portal and the XForms Community Forum as well as being a mentor for the 2007 Google Summer of Code program. This blog was originally posted on UnderstandingXML.com. Kurt lives in Victoria, British Columbia with his wife and family.

Technorati Tags: