Analysis 2009: XForms and XML-enabled clients gain traction with XQuery databases

By Kurt Cagle
January 6, 2009 | Comments: 3

I'm beginning to despair about XForms, which is perhaps a good sign. XForms is perhaps the oldest of the W3C technologies that has yet to either die completely or really dramatically take off, and for all that it has some real beauty of design and thought to it there are pieces of XForms which are just plain ugly.

2008 has seen a fair number of these ugly edges of XForms sanded down, however, and the XForms 1.1 specification should actually become a formal recommendation early this year as well. These should help resolve a number of the glaring holes in the 1.0 specification and offers at least the promise of integration with XPath 2.0 as well (which is in fact a huge step forward).

More to the point, however, XForms has now become the focus of not just one but several different implementations. Orbeon has continued to establish its position as the dominant player in the nascent industry, though XForms products by IBM (Lotus Forms, formerly the rather unwieldy IBM Workplace Forms), the XForms extension for Mozilla Firefox, the Server/AJAX based Chiba XForms, FormsPlayer, Picoforms, XSLTForms and the Ubiquity project, all attest to how full (and competitive) this field has become. Additionally, tools such as xFy provide XForms like capabilities, even though they may not hew precisely to the XForms standard.

There are two factors that have long held XForms in check. The first is that XForms is not a complete solution to anything - it depends upon having an XML data server that can also persist or process the XML sent to it. Without that, XForms is simply a very complicated toy language.

I do not find it at all coincidental that as XQuery has emerged to provide a data abstraction layer for document-centric content, XML databases have also gained traction, and 2008 provided a good example of that. MarkLogic released their MarkLogic 4.0 XML Server in September (I reviewed it last November), bringing their XQuery implementations to contemporary standards (and hired Micah Dubinko, noted XForms guru)  The eXist project (a personal favorite of mine) released their 1.2 branch this year as well, giving a significant boost to the performance of the product and expanding its native library significantly. IBM released updates to their widely used IBM DB2 PureXML Server to bring it in line with current XQuery specifications, and has significantly stepped up their marketing efforts there. Oracle's acquisition of Sleepycat in late 2006 resurfaced in 2008 as Oracle Berkeley DB XML while EMC/Document acquired XML database company X-Hive to incorporate into its offering as the EMC's X-Hive/DB8 Server. I'm planning on reviewing all of these, along with DataDirect's XQuery bridge, later this year.

XML Databases drive XForms. That has been demonstrated over and over again in this industry - indeed, much of the XRX patterns described earlier in this series are a direct result of this realization. Once you have an XML database in place, the desire to work with the content via some type of forms interface becomes very compelling, especially for mixed data/document structures.

This realization has obviously occurred to those buying up the XML databases as well. IBM bought up Pure Edge a couple of years ago, in anticipation of this, but more recently, they and FormsPlayer creator Mark Birbeck joined forces in order to build a new open source XForms engine called Ubiquity. Using a progressive capabilities architecture, Ubiquity is an AJAX based client engine that is intended to be run in any browser that has contemporary JavaScript support. Given that the project started early last year, the progress that Ubiquity has made in implementing not only an XForms engine but a SMIL layer and RDFa as well is nothing short of stunning. This is definitely a project to watch in 2009.

My expectations for XForms in 2009 are consequently quite high. I think that by the time the year is out, every XML database will be paired with either an open source XForms component or will have produced an embedded XForms layer of their own, and most of these will be running at least a subset of XForms 1.1. Because many of these are designed to work in an AJAX layer on top of existing browsers, it also short circuits the other major block to XForms adoption - Microsoft's lack of interest in the technology.

I think another company to watch this year in that space is JustSystems with their xFy product, though I personally think that they should make the investment and move to a full XForms compliant system. They have something similar at the moment, but as IBM found with their PureEdge solution, the market seems to be moving away from pure proprietary languages, even XML languages, and the benefits of maintaining an XForms layer will likely outweigh the development costs.

You might also be interested in:


Hi Kurt,

Great article! A nice summary of the XForms standard. I think that XForms is a bit like SVG. A great standard but one that is held back by lack of browser support from Microsoft. I hope that Google's chrome can change all that.

I hope you can tag this as an XRX article since it seems to support that architecture.

As I commented elsewhere...

I just don't get what the benefit is (of Xforms) over HTML Forms ((X)HTML + CSS + Javascript)?

Now moving forward, if I want to use XForms I use ubiquity-xforms which is bascially a *hack* to get the HTML to behave as if it was an XForm...?

Why not just create HTML?

If it's (percieved as) useful technology, people will want it (the plug-in I mean)... For example: Flash Player anyone?

IMHO comparing SVG (adoption) to XForms is wrong. Organisations like Mozilla, Apple, Opera, Google want the open web to succeed, Microsoft wants a competing technology - a technology that can do 90% of what the (proprietry) Flash Player can do is (very) appealing.

From what I understand MS intends to support SVG in future versions of IE - the way XAML is parsed by IE is very similar to SVG...

What XForms gives you is the ability to work with XML data in a model that minimizes the amount of scripting that you need to do to support content. For comparatively simple applications, XForms is probably overkill, but it doesn't take much for that threshold to be reached.

HTML Forms are strictly name/value pairs - there's no intrinsic structure, no validation, no constraints, and to add these in you have to do a lot of work which generally limits the portability of such code. XForms is considerably more robust, and works especially well for those situations where you have from eight to ten elements on a page on up.

News Topics

Recommended for You

Got a Question?