On XForms

Several months ago, I wrote a post about my XForms development in the Scholars’ Lab as part of a research project. I’m currently working on two research projects that utilize the standard: EADitor (Encoded Archival Description management and dissemination framework) and Numishare (geared towards online delivery of numismatic collections, though other artifacts can be represented). Despite its promise, XForms has not quite swept up the library world yet (though it is most definitely generating some buzz). The W3C standard is a definition for creating dynamic webforms that handle complex, hierarchical XML data–the type of stuff libraries deal with daily. However, only in recent years have XForms processors matured to the point they are ready for mass-market consumption. There are numerous private firms developing XForms applications, including Wachovia, Cisco, and Pfizer. It is also used to some degree in the academic community. As far as I am aware, not many institutions are running it in production, though some are rapidly moving in that direction. The XForms4Lib listserv created in the fall has 80 members from across North American and European academia.

Which brings me to my point.

Matt Zumwalt, active code4lib member and Ruby on Rails/institutional repository developer, boldly declared XForms to be dead. I offer this critique:

There are some inaccuracies in this post that I would like to address. First of all, HTML 5 forms do not supplant XForms as an option for collecting user inputted data. HTML5 is much simpler, and thus has broader appeal. XForms enables the creation of much, much more complex models, with far more sophisticated controls and validation. Moreover, if XForms was a dead language in January 2008, with the release of the HTML5 specification, and that IBM had dropped support, then why do you suppose the XForms 1.1 specification was released in October 2009, edited by a representative of IBM?

No, XForms is very much alive. It has a small, but very active community, which is especially visible with the Orbeon development community. XForms is best used as a definition of dynamic forms that are processed server-side, not in the browser (which pushes a lot of processing demand onto the user, which isn’t good). There are some good, open source frameworks out there. Orbeon is the best, and has many users from both industry and academia, including Pfizer, Leap Frog, Wachovia, UCSB, Stanford, and the National Archives. In fact, Orbeon XForms applications form a large part of the enormous workflow of the NARA Electronic Records Archives project, which is a multi-year project contracted to Lockheed Martin and has a financial backing of close to a half a billion dollars (I have heard). XForms, dead?

A lot of the design flaws you describe are in actuality implementation flaws. Development of a Rails-based framework seems to me like an enormous waste of time and money. You can adapt the MODS editor developed by Brown to such a task. It has already been proven that you can interact with metadata delivered through REST from a Fedora repository. And MODS is fairly simple as a a metadata standard. Care to take a stab at TEI or EAD?

When you began your research in 2007, Orbeon was a fairly young application. But the standard and its delivery and processing applications have evolved since then. Only in the last two or three years has XForms grown into a viable solution. Moreover, since it is a W3C standard, you can pick your forms up and migrate them to a new framework fairly easily. Is your Rails application sustainable in the long term? Are today’s jQuery functions going to work in 2015’s browsers? These are things you need to consider when contemplating a web form standard.

Fedora is a Tomcat application. So is Solr. So is adore-djatoka, which UVA/Hydra utilizes for jpeg2000 delivery. And so is Orbeon. ActiveFedora and any Rails-based MODS editor seem to me like the third wheel in the repository relationship. But in all seriousness, the sustainability of a boutique Rails application that is heavily dependent on the javascript functions of 2010 should be a serious concern to repository developers. jQuery is all the rage today, but it could blow away in the wind five years from now. This is the very thing that the XForms working group set out to prevent when they introduced a standard approach to dynamic webforms.

Classical archaeology student, Web services developer at American Numismatic Society (@ANSCoins), 3d modeler, former web applications developer in the Scholars' Lab.


  1. Just to let you know that the links from right side are not working. Btw, thank you for sharing with us.

  2. For reference, here is the code4lib article: http://journal.code4lib.org/articles/3916

  3. Hi Matt,

    There are a number of factual inaccuracies in your reply; some of them will be dealt with in a code4lib article due to be published within the next few days. There are a few points you bring up that I want to touch on though.

    XForms, as I said, is useful for creating complex data models. Complex data models can certainly be created with intuitive user interfaces.

    IBM may have dropped support of the Firefox XForms plugin. For what reason, I don’t know, but they have not abandoned the development of XForms rendering tools. They are currently developing Ubiquity XForms (http://code.google.com/p/ubiquity-xforms/), a series of extensible javascript libraries for browser-based XForms support. IBM and Orbeon are not the only developers of XForms processors. XSLTForms and BetterForm are also available. If there was no market for XForms, no one would be developing the variety of applications that exists.

    It is a misconception that HTML5 forms unseated XForms. HTML5 forms are not nearly as versatile as XForms, so the two standards serve different audiences. The user base of the standard is not shrinking, especially not in libraries, where support of XForms has entered maturity within the last few years. As a result, XForms development in libraries is actually ramping up. Several institutions are using such applications in production now or will be in the near future.

  4. Hi Ethan,

    Thanks for reading my post and commenting so passionately. I’ve attempted to address your concerns at http://yourmediashelf.com/2010/07/writing-on-the-wall-xforms-has-been-dead-for-years/#comment-156