In July 2006, the W3C released a new working draft of the XForms 1.1 specification. Aside from adding some interesting...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
new wrinkles to XForms 1.0's capabilities, such as a version attribute for the model element (and some interesting targeting capabilities for processors that are sensitive to such things), new data types for e-mail addresses and ID card numbers, subtle changes to deferred update behavior for actions and new submissions methods it's not a huge and sweeping set of changes. Just what you'd expect going from 1.0 to 1.1 in an XML specification, in fact.
But what this news and the new specification reminded me is that XForms really represents a big step forward from such forms handling capabilities as HTML supports. In fact, many die-hard HTML fanatics have been sufficiently convinced by XForms capabilities to upgrade from their old favorite to XHTML so as to be able to take advantage of XForms capabilities. In a recent blog entitled Why XForms Matter, Revisited (3/19/2006), Kurt Cagle puts it like this: "XForms bears about as much resembles 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…but in many ways XForms is more like the harbinger of a new Web development architecture…" Strong words, from somebody with strong reasons for uttering them (I just also read that he's now launched a focused Web site called xforms.org as well).
The hoopla about XForms comes from its ability to permit clients to manage most of the interaction with users independently, without having to continuously shuttle a stream of requests and replies between the client host and a server somewhere else on the network all the time in the background. XForms permits XML data models (which establish the types of data that appear in a form), constraints (which establish integrity, dependency, existence and other checks on forms data), and bindings (which relate specific input values on a form to variables in a data model or in a program of some kind).
Among other experts, Cagle also believes that those who do understand the data models that stand behind XForms (and other declarative sorts of data environments such as spreadsheets) and that learning XForms helps improve data modeling and model realization skills as well. Though extensions to XForms are sometimes needed to make them do everything Web page designers need (and see preview release 0.6 of the Mozilla XForms extension for a more detailed idea of what this enables), by itself XForms offers a reasonably complete solution for those who need to interact with users and to acquire, validate and manage data from those users during such interactions.
Those interested in learning and understanding more about XForms will benefit from digging into Kurt Cagle's recently completed six-part series on Understanding XForms, available through a link on the W3C Web site. Those interested in exploring more XForms tools and technologies should zip on over to Cagle's XForms.org and take a look around.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics along with IT Certification and information security topics. E-mail Ed at email@example.com with comments, questions or suggested topics or tools for review.