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.