XForms

XForms is an XML format for the specification of user interfaces, specifically web forms. XForms was designed to be the next generation of HTML / XHTML forms, but is generic enough that it can also be used in a standalone manner to describe any user interface, and even perform simple and common data manipulation tasks.

XForms, much like XHTML 2.0 which is being developed and in which XForms will be embedded, is different to previous versions of XHTML. Because of this there is a learning curve for old time developers, but because XForms in general provides a large time savings for the development of enterprise quality web forms, it can be an attractive alternative for many uses.

XForms is not yet ready for general use as of March 2005.

Differences from HTML forms

Unlike the original HTML forms, the creators of XForms have designed XForms to separate control, content, and presentation resulting in a section which describes submission actions, what data the forms apply to, and constraints upon that data, a section which describe what controls appear in the form and how they are grouped together, and various CSS elements that describe various aspects of the forms appearance (this division is often described as the MVC pattern). An XForms document can be as simple to create as a legacy HTML form (by only specifying the submission element in the model section, and placing the controls in the body), but XForms includes many advanced features. In particular, the user can bind data to an xml file, validate against XML schema data types, require certain data, disable input controls depending on circumstances, change sections of the form depending on circumstances, enforce relations amongst entries, input variable length arrays of data, output entries and quantities derived from entries, prefill entries using an xml file, respond to actions in real time (versus at submission time), and modify the style of each control depending on the device they are displayed on (browser versus mobile versus text only, etc.). There is no need for any scripting.

Like legacy forms, XForms can use various non-XML submission protocols (multipart/form-data, multipart/x-www-url-form-encoded), but a new feature is that XForms can send data to a server in XML format. XML documents can also be used to prefill data in the form. Because XML is a standard, many tools exist that can chop and modify data upon submission, unlike the case with legacy forms where in general the data needs to be parsed and manipulated on a case by case manner (although most programming languages eventually obtained library functions that does the parsing, it is not always simple to find and use these libraries). XForms is itself an XML dialect, and therefore can create and be created from other XML documents using XSLT. Two examples where there is useful are 1). XForms can be automatically created from XML Schemas, and 2). XForms can be converted to legacy XHTML forms: this is basically how server side XForms work today!

Software support

At the time of this writing no widely used web browser supports XForms natively, although Mozilla has begun work on an implementation. On January 25, 2005, it was announced that native support of XForms in Mozilla will be available via the installation of Mozilla extension [1]. On February 2, Mozilla Foundation announced beta release of XForms 1.0 recommendation.

Despite this, XForms can be used today through various server-side technologies which convert XForms documents to legacy HTML forms on the fly and transparently to users, including the open source Chiba and Orbeon projects. Also plug-in and flash technologies exist which turn browsers into XForms-compliant platforms. The advantage to the open source server technologies is that the resulting output works in theory with almost any browser existing today (the end user will not necessarily notice that they are viewing an XForms page). The advantage to plugins and Flash XForms technology is that these implementations, because they integrate themselves into the browser, can be more responsive, require fewer server fetches, and can present themselves in more exciting ways (i.e. controls that do not already exist in the browser, like sliding scales, can be added to a page). The trade off is that each client must install the required software. A good solution might mix both of these solutions, for instance testing the browser for Flash and serving a glitzy version for those users, but defaulting to a server solution for other users.