I have few comments on XForms, from someone who has invested pretty heavily in the technology over the years -

I personally think XForms 1.0 failed. As a proponent of the specification for a number of years and a working group member, that's a bitter pill to swallow. I think some of that failure was technical, some of it was sociological.

On the technical side, it was too dependent upon the XML data model. This isn't surprising, given when it was proposed, but the reality has been that for any number of reasons XML never achieved the uptake in adoption on the client that I and many others had hoped for. That's a lesson that's not been lost on the W3C Forms WG, as one of the key areas that we are working on now with XForms 2.0 is that JSON may in fact be a valid flavor of data model.

A second technical factor had to do with the notion of working with data models in toto, rather than simply binding properties to components directly. I don't think this was a flaw, but it was a fairly radical departure away from "the way things were done", to the extent that its taken several years for programming methodologies to catch up. Today, it's no big deal to package a set of objects that are maintained as an internal model and post them up an XHP pipeline, but it took a fairly significant change in the way that Javascript itself was thought about for that to happen.

That XForms had to wait for JavaScript to mature (and increasingly for the emergence of a platform such as jQuery to create a more effective binding language on the client side) before it could really achieve anything approaching cross platform adoption. Putting together an XForms based application layer on a contemporary browser such as Chrome or Firefox in JavaScript should actually be fairly easy, given the building blocks of HTML5, but the need for backward compatibility made universal adoption problematic at best.

A final factor was the lag in adoption of XPath 2.0 on the client, and consequently the inability for developers to extend the XForms language in a consistent manner. XForms is an application layer, and as such, needs to be extensible. Some of the work we're doing with XForms 2.0 is moving in that direction, finally, but its taken nearly ten years to get there.

The sociological factors are perhaps just as important. XForms, like SVG, venture out of the foundational space and into the application space, which meant that support for either spec by principle vendors has always been problematic, as these typically competed with proprietary technologies - and more importantly as product differentiators. The demand for an XForms like solution is certainly there among (especially commercial and governmental) customers, but as these frequently represented big contracts the benefits of an open (and most importantly a vendor-neutral) UI platform remained dubious among the large players.

Moreover, XForms was intended to create an abstraction layer that could then be implemented across different platforms differently, but in my experience, the web UI experience is a bigger factor in application development than cross platform compatibility. People want their web pages to look and act the same from platform to platform, and the idea that one vendor would implement forms pages that differed in presentation from one platform to the next did not sit well with UI designers.

These two factors led to the third factor - no large vendor has specifically carried the XForms torch from the beginning as a concentrated effort. Certainly, IBM has been significant in pushing XForms, but their overall investment in XForms has been comparatively tiny compared to investments in other technologies, especially Java tools. This has meant that over time, XForms based solutions have always been marginal projects, carried out by small companies that were often little more than a couple of people in a garage, and typically without the marketing or investment muscle of a Microsoft, Oracle or even IBM.

This has been true of the other W3C tech as well - indeed, SVG would probably have remained a dead technology if Google hadn't started carrying its banner with Chrome. MathML gained support primarily because science powerhouse Mathematica was willing to promote and integrate it into their offerings.

Finally, XForms exists at the upper end of technical complexity. You have to understand rich hierarchical data structures, the concept of constraint bindings, validation and declarative programming. Name/value pair manipulation can seem so much simpler, and for the typical web form (usually encountered entering in registration information) the overhead of all of these things can be daunting at best, especially if you are not used to thinking about model driven architectures. For web applications, the former is useful, but comparatively speaking, these aren't consumer driven applications - they are b2b type apps. I've been developing XForms applications for years, and my predominant customers are clients developing internal applications, not consumer facing ones.

It's easy to point to the browser vendors and say that it's their fault that XForms never developed, but it's a disingenuous argument at best. They certainly didn't help, but in reality, XForms has not, yet, proved itself to be worth integrating. This is not to say that the need isn't there - it most assuredly is - but the question ultimately comes down to understanding what that need really is.

XForms 2.0 development is underway now, and its shaping up to be an interesting project. While a lot is still sketchy, there are a few things that I think will make a difference down the road, and there are a few factors that I think work in XForms 2.0's favour that weren't there before. Among these:

1) Less X. JSON, inbound and outbound, is seen as a core requirement for any new version of XForms. Internally, this changes things somewhat - you go to a model where attributes don't factor in, for instance. It's possible that this may also translate into a different query language (most likely Javascript, or at a minimum jQuery type selectors) being supportable in that instance, something we're currently discussing.

2) XPath2/XQuery support. It will be possible to use XPath 2.0 constructs, along with XQuery FLOWR statements, within XForms 2.0. This provides much greater support for dates, ordering and grouping, regular expression processing and so forth.

3) Shadow trees and rich widgets. One of the key problems that XForms 1.0 has is that it fails to handle cases such as rich text widgets or components where several elements interact in a control in different ways than the elements individually. One idea being explored right now is the use of shadow trees on data elements that could then be bound to complex controls, such as treeviews, rich text controls and the like, without necessarily being part of the publicly exposed data model.

4) Internal user variables. One key assumption with internal XForms content was the idea that you should be able to store computed information into the model via bindings, but binding mechanism can be complex even for those people familiar with the language. One idea that will likely make its way into the spec is internal user variables that can retain state and be referenceable from within XPath expressions.

5) Attribute Value Templates (AVTs). One of the more frustrating aspects of working with XForms is that it's not possible for output values to directly affect user interfaces. AVTs provide that bridge. You can, for instance, use an AVT to change classes in an interface:

<div contenteditable="{if (instance('foo')//state = 'live') then 'true' else 'false'}">This is a block of text.</div>

This would then make the text editable if a certain state is set, without necessarily needing to reflect this in the data model directly.
6) Functional extensibility. One goal is to provide an extensibility framework for XForms that make it possible for users to add new functions or service libraries to the EXPath (or JSON) evaluation language. Some of them may be simple as the doc() function, which will make it possible for a component binding to load in a document on the fly then access the underlying XML without necessarily going through the process of setting up a formal instance to do so. Similarly date and number formatters and ingesters can process and modify the presentation of dates and numbers within an XForms page. By creating a systematic interface for doing so, XForms can become much more robust.

7) Namespaceless elements. One common complaint with XForms is that namespaces can be cumbersome to work with. An idea being floated is the notion of an XForms implementation that can work without namespace declarations or namespace requirements in bindings. These might have slightly different names than the existing specification, perhaps such as <xfinput> to differentiate it from the HTML <input> element, but the idea is that it should be possible to work with these without having to spend time getting caught up debugging namespace logic.

8) Templates, etc. There are actually a number of changes that have made their way into the XForms 1.1 specification (and are nearly universally adopted) such as the origin attribute, the use of templates within XForms, dynamic switches and toggles and so forth that dramatically improve on the 1.0 language. However, because many people encountered XForms in its 1.0 incarnation, they aren't aware that these improvements now exist. XForms 2.0 will carry these improvements through and work to simplify other rough edges from the original spec.

9) jQuery and HTML5 compatibility. A big problem for the evolution of XForms has been the lack of a consistent and compelling platform for development, coupled with a backward compatibility issue. In reality, it may be necessary to cut the chord and make the assumption that any XForms 2.0 implementation will only work on HTML5 compatible browsers. This might also force a shift in underlying implementations to integrate with at least jQuery, as this tends to be a problem that many current implementations are struggling with, even as jQuery is becoming a near universal default for rich websites.

10) Finally, I know that we're looking at an outreach effort with some of the major vendors to help support the next version of XForms, preferably via a client-side solution but worst case via a relatively easily portable server side solution. More to come on that.

Keep in mind that none of these are set in stone, though they do represent a general lean in the direction being taken by the working group, as well as looking at what customers are demanding of the technology.

I think there is still a need for XForms, but its a need that itself needs to be tempered with the reality that what seemed like a good idea in 2002 may not necessarily be as attractive in 2012. I think that's what's happening now within the Forms working group, and as such XForms might actually end up becoming more significant in the long run than it is now.
Shared publiclyView activity