XForms is an entirely legitimate offspring because it achieves two worthwhile purposes: It further elevates the position of XML as the medium of exchange for Web site data, and it eliminates a number of weaknesses in standard HTML forms. (Thats a polite way of saying that the premier goal of XForms is to replace HTML forms.)
For those unfamiliar with HTML forms, a form is a part of a Web page an input field, a text box, a radio button that includes an input control. XForms, meanwhile, is built on an MVC (Model-View-Controller) architecture. The structural details of the data manipulated by a Web form are purposely separated from the forms visual details. Thus, XForms code that describes the data to be input and output is not entangled with the code that displays that data a common problem with HTML forms.
Indeed, XForms takes things a step further, leaving the visual details of the display entirely up to the user interface. For example, in HTML forms the multiple options presented by a “select” tag are rendered as a menu. In XForms, the programmer can render those options in other ways. In other words, the display portion of an XForms form describes the intent of the forms controls, not their appearance.
All this factoring makes XForms easier to work with than HTML forms. For example, a change in the structure of the data requires less alteration of the display code. In addition, data is exchanged between Web form and server using XML. And XForms can call upon its cousins XSL and XPath for input format and type validation (for example, making sure that a quantity input field contains a positive integer), as well as for calculations and special formatting.
Consequently, much of a forms business logic that must now be done by scripting can instead be done by XForms. The result is cleaner, and easier to read as well as maintain.