XForms has been Dead for Years. What to do?
Posted on 20. Jul, 2010 by matt in Explanations, Hydra
At Open Repositories in 2007, I gave a presentation on Simplifying Fedora Frontends with XForms and Fedora Disseminators (PPT). This work showed how to leverage Fedora disseminators to embed XForms directly into your Fedora repository, thus embedding a basic edit interface directly into your archival objects. The reference implementation used Orbeon XForms and a whole lot of XSLT. Shortly after giving that presentation, I dove into Ruby on Rails in a big way and swiftly realized that I was gazing up the wrong tree. By comparison with Rails, my development process was slow, my code was difficult to test or debug, and the user interfaces I had created were kludgy, ugly and difficult to refine. From an architectural perspective, the XForms+Disseminators work was a great concept, but from an engineering perspective, it had serious flaws. The most damning flaw was the fact that it put the ideals of software architecture ahead of the interests of real-life user interaction.
After careful consideration, I abandoned XForms and threw my energy into putting Rails on top of Fedora Repositories, which I reported on one year later at Open Repositories 2008 in a presentation called How we Integrated Fedora into Ruby on Rails and How You Can Use It. This in turn lead to the development of ActiveFedora and the resulting Hydra framework.
I was not alone in my decision to abandon XForms. In January 2008, the W3C published the first draft of HTML5. Later, the funding for the Mozilla XForms project evaporated. Since then, to my knowledge, none of the browser manufacturers have commited any resources to supporting XForms. To contrast, all of the major browser manufacturers have committed to support HTML5 (with HTML5 Forms) and have already made substantial headway in that direction.
Meanwhile, my old presentation from 2007 has been floating around the web. I periodically get emails from people who are enthusiastic about using XForms with their Fedora repositories. Every time that happens, I do my best to discourage them and promise to put up a blog post enumerating my criticisms of XForms. Thus, with sincere apologies for the lengthy delay, here is the quick rundown of my thoughts on XForms and a bit of info about how MediaShelf is dealing with complex, hierarchical XML in the repository-driven applications that we build.
XForms are to Beta Cassetes as HTML5 Forms are to VHS
XHTML2 and, by extension, XForms have lost their bid to become the chosen replacements for HTML4. HTML5, CSS3 and HTML5′s Forms (formerly WebForms) are the official successors, and they are looming large on the horizon. All of the major browsers already support them. The further you sink your legs into XForms, the harder it will be to keep up when this wave hits the mainstream.
In case that’s not ’nuff said, let’s look a little more deeply.
XForms is a dead technology.
Technologies are like languages — Latin is a dead language but is still used (and useful) in rare cases. The same is true for XForms. If you choose to use XForms, you’re choosing to use a technology that will never enjoy broad adoption and will increasingly fall short of contemporary development practices.
Losing the battle to become a standard doesn’t always kill a technology, but in this case it did. XForms was dead in the water in 2008 when the W3C decided to favor HTML5 over XHTML2. The writing was on the wall when the major corporate support for XForms quickly evaporated (ie. IBM cancelled its funding for the Mozilla XForms Project, which to my knowledge has never seen any work since).
While some organizations do still use XForms, this doesn’t mean that the technology is strong — after all, plenty of hefty corporations still run and spend money on maintaining cobol apps.
XForms makes it difficult to stay abreast of contemporary interface and interaction design.
The structure and conceptual framework of XForms feels strange and overly complex to most developers (especially developers who don’t like declarative languages). This discourages innovation on the part of those developers, who are only going to work with XForms when they are forced to. Since XForms effectively died in 2008, none of the innovations since 2007 have happened in the XForms arena. Case in point: XForms is incompatible with the vast majority of the javascript widgets and plugins floating around out there, which in turn means that unless you re-implement all of those plugins you’re stuck with kludgy, outdated interactivity in your forms.
XForms has some real design flaws
XForms assumes that In-Browser interactivity means Asynchronous XML.
With its rigid fixation on XML, XForms prevents you from taking advantage of non-XML communications.
The very notion of AJAX has evolved substantially since the inception of XForms. In fact, the very name AJAX has fallen from favor because what originally manifested as “Asynchronous Javascript and XML” has now become much more open ended. Notably, convention has drifted heavily in the direction of preferring JSON over XML by virtue of its simplicity and attendant ease of serialization/deserialization. Meanwhile XForms instead focuses on embracing the full complexity of XML, which adds complexity without much, or any, real payoff. Further, with the arrival of HTML5, the predominant conventions, which are not all XML-centric, will become ensconced as the standard.
XForms encourages you to break the MVC pattern in your applications.
Though XForms uses an MVC model internally, it encourages you to break the MVC model in your application by forcing you to embed decisions about your XML schema(s) — which are an implementation detail of your model — into the XForms. Thus, you’re forced to put representations of your model into the view layer of your application. This is especially noticeable when your user wants to edit metadata that is actually spread across multiple XML documents (and schemas) in your model — though you can technically handle this in XForms with XInclude, etc, it is far from ideal.
While this is merely bad design when you’ve got just one form in one application, it compounds upon itself as you add new forms because decisions about the schema become replicated across numerous XForm controls within each of your edit views. Any time you want to change something about your model (ie. what attribute to use on a particular metadata field), you have to update all of the corresponding references in all of your forms.
You could add a layer of abstraction in order to at least partially achieve this separation of concerns, but in that case, once you’ve added an abstraction layer, why the heck would you use XForms instead of a regular dynamic form?
How, then, to deal with complex XML?
This brings us back to the real issue at hand. Most of the people who ask me about XForms are building interfaces for creating and/or editing complex XML metadata. Most often they are either dealing with MODS or Qualified Dublin Core. Since the metadata is already in XML, XForms seem like a perfect fit.
Though I was able to offer criticisms, until recently I haven’t been able to offer a complete, viable alternative to XForms. ActiveFedora has supported Dublin Core since late 2008, but that was neither a complete nor a freestanding solution, and it wasn’t any help at all for those poor souls who are coping with MODS. Now, as of last month, this has all changed.
As part MediaShelf’s work on Hydra for the Stanford Libraries, we have created a Ruby gem called OM (Opinionated Metadata). OM is a server-side solution for mapping between your application’s metadata vocabulary and a specific XML structure. In order to use it, all you need to do is provide a single file specifying how your application terms map to nodes in an xml document. Based on that information, it uses XPath and some of the characteristics of XUpdate to give you simple tools for predictably creating, retrieving, updating and deleting nodes within complex XML documents.
Though it’s only in its first stages of development, I think OM has some real promise. We are currently using it in Hydrangea (the Hydra demo application) to edit MODS descriptive metadata and to edit rights metadata based on the Hydra rightsMetadata schema. Also, ActiveFedora natively supports using OM to index complex, hierarchical XML into solr, so a single OM mapping file gets you all of the basics you need in order to use complex XML metadata in all of your application’s Search/View/Edit functionality while putting regular HTML (either HTML4 or HTML5) into your views.
There is much more information to come on OM. In the meantime, go directly to the code.
The OM code: http://github.com/mediashelf/om
The Hydrangea code, which uses OM: http://github.com/projecthydra/hydrangea
Within Hydrangea, check out the OM mapping files for MODS Articles and Hydra Rights Metadata. (Note: Both files also specify custom methods that augment the behaviors provided by OM.) You can see how the resulting mappings (ie. [:person, :first_name] ) are used in the edit form templates for hydrangea articles.
There are some inaccuracies in this post that I would like to address. First of all, HTML 5 forms do not supplant XForms as “the” standard 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. 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 could adapt the MODS editor developed by Brown to such a task, and have it running in weeks, if not days. 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 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.
Ethan Gruber
University of Virginia Library
Ethan, Thank you for commenting. Let me address a few things that I think I didn’t explain clearly enough.
First, complexity in a user interface is usually viewed as a bad thing. That’s why putting the ideals of software architecture ahead of the interests of real-life interaction is a damning flaw in any interaction experience you design.
Second, I did not claim that IBM dropped all support for XForms in 2008. I observed that 1) all of the browser manufacturers abandoned any work on XForms and 2) IBM stopped funding the Mozilla XForms project. You can’t read the tide by watching the direction of a single boat.
Third, when used well, jQuery functions provide enhancements rather than essential functionality. This is good design — provide the most compelling interaction when possible, but always degrade gracefully. This graceful degradation is one of the primary items that we’re polishing thoroughly in the Hydra framework before releasing version 1.0.
Your description of the community of XForms users makes me wonder whether you understand what I mean when I say that XForms is dead. When I get a chance, I’ll post something to clarify.
Thank you for pointing out the benefits of Fedora’s REST API, which MediaShelf wrote in 2007 (on behalf of DISA [http://disa.nu.ac.za/]) so we could explore using XForms with Fedora. Our conclusion from that exploration was to keep the REST API and ditch XForms.
In case you were not aware of the history of XHTML2, you might start with Michael Smith’s presentation on the W3C website [http://www.w3.org/2009/Talks/05-20-smith-html5-xhtml2/] or on slideshare [http://www.slideshare.net/sideshowbarker/html5-and-xhtml2].
Until 2007, XHTML2 (and thus XForms) was supposed to be the successor to HTML4. In a major coup, HTML5 swooped in and claimed the crown. In 2008, the W3C officially named HTML5 as the heir apparent. In other words, HTML5 supplanted XHTML2. This is not speculation; it’s a matter of public record.
The release of the XForms recommendation in 2009 was merely a concession to those who had already committed resources to the losing team. Though it is an official recommendation, it will never enjoy broad adoption nor particular favor within the W3C. This makes XForms a very weak technology to invest in for even the near future. Worse, an XForm can’t degrade to regular HTML, so you’re relying on either native browser support (nearly nonexistent), a browser plugin, or a transformation to make your forms work at all. What will you do in 2015 when a new crop of browsers comes out and nobody bothers to make them support XForms? One thing’s for sure – you’ll be drawing from an increasingly sparse pool of developers who know anything about the technology and an ever-shrinking set of organizations who have any interest in footing the bill.