A profound change is likely about to shake up your world if you’re a web developer, one that I suspect will make the recent efforts in the AJAX space pale in comparison as far as its effect. Very quietly, over the last few weeks, the Mozilla team has been upgrading their XForms capabilities through the use of an XForms extension. It requires that you are running Firefox 1.5.0.1 or above, or Seamonkey 1.0 or above, but frankly, there are very few reasons for you not to be at this stage if you’re a Firefox or Seamonkey fan.

More than two years ago, I wrote a piece in my blog with the name “Why XForms Matter” that examined this technology in some detail, but at the time, the level of support for XForms was rather depressingly thin. A standard formalized in 2003, the XForms 1.0 Recommendation offered up an intriguing vision - an XML based format for the deployment of form fields both within XHTML documents and within other XML environments (such as SVG, the Scalable Vector Graphics language) that would make it possible to make a surprisingly powerful rich client that didn’t have to be extraordinarily heavy in terms of memory footprint, processing power, or speed. What’s more, as a W3C standard, it could be deployed with no royalty costs, could be implemented on a wide variety of platforms in implementations that only had to be compliant to the standards, not to any development language, and couldn’t be held hostage to a company’s need to change their operating environment every time sales figures lagged for the quarter.

The response to this technology, on the other hand, has been fragmented at best, though I have to admit that I should have seen that coming. I’ll get to why in a bit. For now, I want to talk a little bit about the state of the web in 2006. The state of the art in 2006 can be described in four letters A-J-A-X. If you understand AJAX, you have essentially written your meal ticket for the next couple of years. Indeed, right now we are in that state of affairs that I had a feeling we’d be facing right now - there’s a huge demand for AJAX programmers, and a surprising dearth of skilled practitioners. Given that AJAX is only Javascript, XML and a bit of socket programming, you’d think that this demand should have been filled pretty readily … but its not really all that simple.

AJAX programming represents a fairly radical jump if you’re used to traditional server-side applications, though if you were playing with Macromedia Director or Flash nearly a decade ago, you’d intrinsically recognize what’s going on here (indeed, note to hiring managers - get good Flash programmers if you’re looking for people who understand AJAX … they’ve been doing it for years and years). The idea behind AJAX is that we are shifting away from the model where the server becomes responsible for the presentation and state management of an application and toward the model where the purpose of the server is to dish up structured data content. Not only does it speed up your applications by an order of magnitude because you’re not waiting for the server to spit content out to you fast enough, but it also means that you can actually handle most of your state management there on the client as if it was a form, something that should be familiar to VB developers worldwide.

However, there are some intrinsic problems with this model. One of the first is the fact that Javascript is nowhere near as easy as it seemed a few years ago. It’s actually always been a fairly powerful and complex language, because it is a language that treats functions as objects, treats instances of functions as objects, and by automagically hiding the type conversion from the developer makes it possible to start concentrating on some fairly complex behaviors that usually were well outside of the feasibility stack because too much time was spent getting “Hello, World” working.

AJAX also tends to push a fairly heretical idea onto the plate - the notion that you can send Javascript objects up and down a pipe in some serialized fashion and have them get instantiated in some other context. Now, personally, the idea of doing this gives me the willies … because it opens up the potential for serious mischief, not least of all, but it is also a powerful modality for programming by moving objects around as if they were free-floating entities in a distributed sea. To me, it also tends to blur a critical boundary for me concerning the point at which point code becomes data, but it may be that this is because I tend to see Javascript as a lightweight imperative framework that takes the declarative code of XML and “does” things with it.

However, there’s another problem with AJAX — as a language, Javascript is not in fact terribly efficient as either a means of representing complex data structures or of providing a consistent internal framework for manipulating those data structures. Even with such technologies as E4X, there’s still a tremendous degree of adhocracy going on right now that makes it difficult to do one of the things that Javascript was, ironically, intended to do well - handle form content, especially in distributed environments.

I’ve been working a lot lately with mixed XML/Javascript frameworks, and curiously enough, the more complex the applications become, the more that they in fact begin to resemble … well, XForms. You have one or more XML data stores that can represent anything from a personal schema to a description for an entire set. You have a series of bindings that determine the boundaries and secondary processing of data between components, you have event notifiers that get passed from object to object in a subscription oriented framework. All of these facets, and more, are critical pieces of the XForms space.

In point of fact, you can create some incredibly rich “web experience” applications that are mixed XHTML and XForms, and can do so in a remarkably short amount of time. These are not simply empty text fields that you lay out as you do with HTML >input< elements - XForms bears about as much resemblance to HTML forms as a Bengal tiger has to a ferret. If you go back far enough you’ll probably find that they share a common ancestor (they do, in fact - a weasel-like tree dweller called a Miacis, from about 50 million years ago), but in many ways XForms is more the harbinger of a new web development architecture where the application (the web page) holds a model that either populates or is populated by various XML form elements. When the model changes, so do the form element contents. When the form elements change, so does the model. This is handled automagically in the background, using the power of XPath expressions and data bindings to create sophisticated applications.

So how does this differ from the “traditional” AJAX application? The difference comes from the nature of that automagic, which is far from being either automatic or magical in the latter context. In an AJAX application, you explicitly sit on the page load tag to grab an XML (or related) resource from the server, creating an asynchronous call that will update an explicitly defined model, then write more code that will walk through that XML model and either pass it to an XSLT transformation or run it through more DOM manipulation code in order to explicily populate the fields in question in the web page (any more explicit and it would require an X rating). You can cut this code down considerably with some carefully coded libraries, but these libraries add to the overhead of both loading and maintaining the page, sometimes significantly, and if they are not well written can also add a considerable burden to the debugging department.

On the other hand, an XForms like architecture defines XML data models, constraints, and bindings explicitly as rules given within an a declarative XML format. This declarative form works in a manner similar to that of an Excel spreadsheet. In Excel, for instance, you define both blocks that hold initial data then you have functional blocks that perform calculations either upon the initial data or a previously defined functional block. What you end up with in this kind of declarative “program” is an application where the “answer” may in fact be a lot of different pieces of information, where the only action involves the changing of one or more initial values, and where constraints will at a minimum prevent you from entering erroneous data.

Whether talking about spreadsheets or XForms, the one dominating factor in both cases in their development is the recognition that you are creating such a form in its entirety, at every single point within the application process itself. This is a fairly subtle concept, but its an important one. When you create an imperative script, at any given point in the process that script will be incomplete, perhaps to the point of being unrunnable. This means that most development requires that you create fairly complex modules, run (or compile) them, then spend time trying to figure out why you’re not getting any answer coming from out of the black box. It necessitates at the beginning having a comprehensive idea about what pieces you will need to construct the application, and so places a premium on planning in environments where planning and design budgets are usually pushed to the absolutely minimum.

In a declarative model such as XForms, however, so long as your syntactical structures are intact (i.e., so long as you have clearly defined well-formedness) your model will run. You CAN, of course, design forms that do not check for valid data, so there is no guarantee with XForms (or Excel for that matter) that your model will return anything meaningful. In other words, garbage in - garbage out still applies. However, introducing constraints in such an application is also not hard to do, making it much more difficult to insert garbage in the first place.

However, it also means that when you’re dealing with declarative forms such as this, you DO still need to understand the model (indeed, to a certain extent, you need to understand the model better), but one of the things that I’ve found over the years is that models very seldom spring into life fully-formed. Indeed, its perhaps more accurate to say that the model for any form of even reasonably complex interface tends to emerge throughout out the lifecycle of the process. I believe that XForms makes this process easier, because it becomes MUCH easier to track (and change) dependencies in an XForms based model than it does to change such dependencies in either object oriented code (refactoring) or scripting (wholesale panicking).

XForms is not a complete solution, though its usually close to it. Sometimes you need to write extensions, and many XForms engines have mechanisms for extending the default XPath implementation in various ways. Additionally occasionally you will run into situations where you want to replace the default XForms standard controls (for example, turning an <xf:output> element into an image display control). The XForms model in this case works very well with other binding languages (such as Mozilla’s XUL or the SVG sXBL binding language), as I will be showing in a subsequent column on XForms (highlighting a non-trivial XForms application in Mozilla Firefox).

However, for all that, the XForms idiom is surprisingly robust. For instance, if you wanted to create multiple author entries in a papers submission form in HTML, you would have to create entries for each author grouping in turn. In XHTML+XForms, on the other hand, you’d need to do only two things: build the model of the content you’re wanting to display:

<xf:model id="data">
    <xf:instance>
        <d:submission>
            <d:author>
                <d:firstname>Kurt</d:firstname>
                <d:surname>Cagle</d:surname>
                <d:middleinitial>A</d:middleinitial>
                <d:affiliation>Metaphorical Web</d:affiliation>
                <d:email>kurt.cagle@gmail.com</d:email>
                <d:website>http://www.understandingxml.com</d:website>
            </d:author>
            <d:author>
                <d:firstname>James</d:firstname>
                <d:surname>Kirk</d:surname>
                <d:middleinitial>T</d:middleinitial>
                <d:affiliation>Starfleet</d:affiliation>
                <d:email>james.kirk@starfleet.mil</d:email>
            </d:author>
            <d:author>
                <d:firstname>Cecilia</d:firstname>
                <d:surname>Jones</d:surname>
                <d:middleinitial>E.A.</d:middleinitial>
                <d:affiliation>University of Victoria</d:affiliation>
                <d:email>cecejones@uvic.edu.ca</d:email>
                <d:website>http://www.cecesite.com</d:website>
            </d:author>
        </d:submission>
    </xf:instance>
</xf:model>

and use an XForms repeat block to reference this:

    <xf:repeat nodeset="/d:submission/d:author">
            <fieldset>
                <legend>Author</legend>
                <div>
                    <xf:input ref="d:firstname">
                        <xf:label>First Name: </xf:label>
                    </xf:input>
                    <xf:input ref="d:middleinitial">
                        <xf:label>MI: </xf:label>
                    </xf:input>
                    <xf:input ref="d:surname">
                        <xf:label>Surname: </xf:label>
                    </xf:input>
                </div>
            </fieldset>
        </xf:repeat>

The beauty of this as well is that as you change the values of the respective input fields, the XML data model will automatically be kept in sync - you do not need to write complex iterating code to do it. You can easily add or remove entries in the same manner (code which I’ll show in my next XForms post) and do so with minimal (and in most cases no) additional scripting.

The combination of XForms, XHTML, CSS, SVG, XBL-like bindings and the like can make for a wide variety of applications. Certainly, XForms could easily replace tabular presentation forms, but could just as easily be used for building rich slide-show applications, multipane websites (complete with tabs, side tabs, button sets and related controls), multipage wizards, even game environments.

One reason for this diversity of form comes from the fact that the language works with abstract components that have known programmatic interfaces but not necessarily known user interfaces. I’ve heard, in various circles, some mocking of such abstractions, but one of the things that I keep rediscovering is that the set so covered actually works quite well in hitting more than 99% of all potential components, either by themselves or in aggregate. A tabset, a button bar, radio buttons and drop-down selectors are all instances of a <selectone> component in that they all handle the same task (choosing one item from a set and performing an action based upon that selection) albeit with different skins.

In the ensuing couple of weeks, I will be looking at two or three such XForms examples in detail within Firefox. I hope to keep them relatively simple but meaningful (there are four or five calculator objects out there which are cool to look at but which are too complicated to use as pedagogical examples, for instance). It’s a technology worth coming back to, especially in this day and age of increased focus on the browser. It can help tame some of the thornier AJAX programming issues, and I suspect in the end will represent the next major leap in web technologies.

Given the rising proliferation of “component toolkits”, I see a coming period where everyone’s going to be trying to get THEIR component interfaces accepted as the “standard” ones. The XForms components actually handle almost all of these cases, provides a standard, open, non-proprietary solution that suffers only from lack of education and exposure, and with its presence now in Mozilla (and numerous versions available in IE, including both ActiveX and pure Javascript versions) I see XForms poised to become the de facto forms technology within the browser world.

Kurt Cagle is an author and columnist specializing in XML and Web technologies. He lives in Victoria, British Columbia.