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.
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.
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.