From its first days, the Web has been torn between idealists and pragmatists. The idealists envision a global, interconnected network of free and open exchange of information with truth, justice, and liberty for all. The pragmatists envision getting their work done before 5:00 p.m. and going home to spend time with their families. The idealists evangelize technologies like Standard Generalized Markup Language (SGML), Extensible Markup Language (XML), Scalable Vector Graphics (SVG), Cascading Style Sheets (CSS), and Extensible Hypertext Markup Language (XHTML). The pragmatists turn to HTML, JavaScript™, tables, and Flash. The idealists join the World Wide Web Consortium (W3C) and attend conferences like Extreme Markup Languages and WWW 2007. The pragmatists join the HTML Authors Guild and attend conferences like Web Design World. The idealists read books like Weaving the Web and Effective XML. The pragmatists read books like Ajax in Action and Designing Killer Web Sites.
The latest bone of contention between the two camps is over the next-generation forms technology: Web Apps 2.0 or XForms. There's a lot of talking back and forth over one another's heads because neither side sees what the other is trying to accomplish, and neither is speaking the language of the other. However, the gulf between the two camps isn't unbridgeable. Many idealistic technologies such as XHTML and CSS have seen widespread pragmatic adoption because they offer real, practical benefits for the work pragmatists are doing. The pragmatists are understandably reluctant to jump on every W3C bandwagon as soon as the first working draft is posted -- they prefer to wait a few years until new technologies are both reliable and available among their user base. They aren't early adopters, but they are adopters, if the technology makes sense for them and the tool support is adequate.
XForms is an idealistic effort to solve many pragmatic problems that bedevil Web developers today. Pragmatic solutions based on incremental improvements to classic HTML forms are good as far as they go, but they don't reach nearly as high as XForms does. However, precisely because XForms reaches higher, it falls farther and makes a bigger thud on impact when it fails.
Because XForms is more ambitious, it's both more promising and more disappointing: promising in what may be possible one day not too far off; disappointing in that these things aren't possible today. Nonetheless, it's important to understand what XForms attempts to achieve, in order to fairly judge the alternatives. If the goals XForms is striving for aren't your goals, then it won't be interesting. If the goals XForms is striving for are of practical interest to you today, however, then it may be worth your while to struggle through the inevitable birth pains of a new technology.
The first thing you need to understand about XForms is that it's not just for the Web and not just for HTML. It's certainly not just for classic desktop browsers like Firefox and Microsoft® Internet Explorer. XForms is designed to work well in many other environments: mobile phone browsers, audio browsers, and things that aren't browsers at all. For instance, OpenOffice 2.0 uses XForms as its underlying forms technology. It's hoped that in the future, other products that currently use proprietary forms technologies, such as Microsoft Word, Adobe Acrobat, and the Universal Business Language (UBL) should be able to migrate to XForms. (Whether they will do so is an open question.)
Furthermore, like XML before it, XForms is designed to separate intention from action, meaning from presentation. It's designed to be a generic description of the input a form needs to collect. An XForm says little to nothing about how the form will be rendered or how the user will interact with it. The same form can be rendered one way in a browser, a different way in a phone tree with touchtone and voice-recognition input, and a third way on paper to be filled out with ink and scanned in using optical character recognition.
The question to ask yourself is whether you need multiple renderings of the same form for different environments. Many applications don't need this. For instance, if you're writing a simple Web site poll for amusement's sake, HTML in browsers may be where you start and stop. However, larger systems may benefit from more generic approaches. For instance, a system to collect shareholder votes typically lets people vote by phone, paper, and the Web. Here a single forms technology that can support all three options from one source document will be useful.
Maybe you don't need this functionality today, but you may be able to use it in the future. For instance, imagine updating your blog in real time by calling into the server on your cell phone and dictating (not typing!) a story. Voice recognition isn't good enough to support this today, but it will be. When that day arrives, adding voice-input support to an XForms-based blog will be a fairly simple project, because the forms themselves won't need to be rewritten. However, HTML-form systems won't support this at all. Again, maybe I'm looking too far into the future and should focus on the here and now rather than the science fiction interfaces of tomorrow; but these science-fiction problems are what XForms is trying to solve.
The Web may have sold a lot of computers, but it's never been just about computers -- at least, not just about traditional desktop computers. In the near future, the most common device for accessing the Web will be a mobile phone. Perhaps the second most popular device will be a human-powered laptop running a custom version of Linux® on an underpowered processor. Many people will continue to use text-mode browsers like Lynx. XForms is designed to work well in all such environments, not just graphical user interfaces (GUIs) displayed on 30-inch monitors with millions of colors.
The trick to making multiple-device support work is to separate what a form collects from what a form looks like. For example, a form that asks for a shipping and billing address may appear on one page in a traditional Web browser like Firefox. However, it can easily be split into two successive screens on a smaller device like a mobile phone. It can even be nonvisual if the form is filled out by talking rather than typing. XForms make no assumptions about what kind of device is used to fill out the form.
Forms aren't just filled out by people. They're also used to communicate between processes. For example, an office manager may enter requisitions for office supplies into a thick-client GUI program running on a Microsoft Windows® computer. This program can then search for the best prices for each item at OfficeMax, Staples, Office Depot, and Laser Monks before ordering. The office manager fills out a local form in the program, which then copies that information into the form at the store with the best price. Perhaps a human doesn't even need to be involved in the process. A smart printer can recognize when it's running out of toner and automatically reorder.
For this scenario to work, the forms have to be accessible to other programs, not just people. The fields must be labeled with names other programs can identify. The labels have to be clearly attached to particular fields in the markup, not merely in the visual presentation of the page. Furthermore, it's helpful if the form can specify that a field expects an integer, a decimal number, a date, a date in the future, a legal zip code, and so forth.
In this use case, not only is the presentation separated from the markup, but there may not be any presentation. Humans are smart and can use implicit clues like the position of fields on the page to tell what data is expected where. Computers can't: They need more help. XForms is designed to give it to them. The more explicit the form is about what can be entered into it, the easier it will be to automate interaction with the form.
Internationalization and localization
Non-ASCII data is one of the traditional bugaboos of forms programming and the Common Gateway Interface (CGI). Early HTML and URL specifications left a lot to vendor imagination when it came to how to encode and submit words like resumé, much less Χηνος or ⽲. This situation has improved to some extent in the last 10 years, and some standards have emerged. Clearly though, going forward can't involve going backward. Unicode must be enabled from the get-go.
XForms uses XML as its underlying serialization form. When a browser or other client receives an XForm from a server, it receives XML. When it sends the form data back to the server, it encodes the data in an XML document. XML documents are Unicode. They can be stored in other encodings, but the translation between those encodings and Unicode is simple and deterministic. When you work with XML, encoding problems go away. There's no chance that one side of the communication will read a document as ISO-8859-1 and another as UTF-8. This makes it possible to fill out forms with Greek, Chinese, French, Hebrew, and hundreds of other languages. To quote Robert Bringhurst, no longer will it be necessary to hope "that no one will ever mention crêpes flambées or aïoli, no one will have a name like Antonín Dvořák, Søren Kierkegaard, Stéphane Mallarmé or Chloë Jones, and no one will live in Óbidos or Århus, in Kromìøíž or Øster Vrå, Průhonice or Nagykõrös, Dalasÿsla, Kırkağaç or Köln." (The Elements of Typographic Style, Hartley & Marks Publishers, 2002, p. 90)
Of course, true internationalization and localization go beyond merely letting people type their names and addresses using non-ASCII letters. It's also necessary, for instance, to allow forms in languages such as Hebrew and Arabic to flow right to left rather than left to right. Again, the separation of presentation from content comes to the rescue. Nothing in an XForm says that fields must be laid out one way or the other, so the local renderer is free to use whichever direction makes sense to it.
Of course, hints are sometimes helpful to tell the renderer whether it's dealing with English or Arabic. Again, XML comes to the rescue. XForms allows full use of the xml:lang attribute, Unicode bidirectional marks, Ruby text, and other arcana that don't matter much in English but are critical in some other languages.
Finally, the forms themselves need to be localized. The same form must be able to load its labels and other human-visible content from resource files that have been translated into various tongues. Just like when you're writing thick-client GUIs, you don't want to embed translatable strings in the source code, because the translators usually aren't programmers.
One of the least obvious but most important goals for XForms is accessibility. An XForm shouldn't work only for sighted users with complete manual dexterity. It also needs to work for anyone who's visually, manually, or otherwise impaired, either temporarily or permanently.
This doesn't just include the obvious categories of blind and physically handicapped users. It means the rest of us, too, because everyone is handicapped some of the time. Many people surf the Web on tiny cell-phone screens with numeric keypads. People may fill out XForms while driving using an audio interface.
In an increasing number of jurisdictions, accessibility isn't just a good idea. It's the law.
It's no surprise that people filling out forms make mistakes. All too often, you're asked to type your e-mail address twice, just to be sure you didn't make a typo. A lot of complicated JavaScript code has been written to verify basic constraints such as a credit-card number having the right number of digits or an expiration date being in the future, not the past. Of course, you can write checks like these in JavaScript code; but saying what the constraint is is about a hundred times simpler than writing the code to check it. XForms wants to make these checks a lot easier to write by making them declarative and more direct. Therefore, they're more likely to be written in the first place.
Some constraints can be checked as the user types. For example, if an input field is declared to have type in it, the browser may ignore any nondigit keys the user presses. Other browsers may instead check the constraints before submitting the form and alert the user if they find a violation.
Of course, a robust Web application can't rely on anything the client submits. A malicious user can try to hack the system by changing the total price before submitting an order. Only the person validating the data can trust the data. The client can trust what the client validates, but the server can trust only what the server validates.
For this reason, XForms is designed to allow validation on the server side as well as the client. Trust, but verify. All client-submitted data can (and should) be tested against a schema to make sure it conforms to the model. It's possible to test the input to traditional Web applications based on HTML forms as well, but XForms endeavors to make this much easier and more robust, almost to the point where it's easier to test than not to test. This should close a lot of small security holes around the Web.
A system is only as fast as its slowest part. In Web applications, the performance bottleneck is usually either the server (if it's processing a lot of connections) or the network connection between the client and server. It's important to minimize the work both of these have to do. The performance bottleneck is rarely the client, so any work you can offload from the server or the network to the client is almost certainly a performance win.
One severe limitation of current HTML forms is that every calculated change to a form's values requires a round trip to the server. The server has to receive the input, process it, and return a new form to the client. Sometimes this is essential, as when the server is returning information from a database only it has access to. However, sometimes there's no fundamental reason the work can't be done purely on the client. For instance, the client can easily total up the prices of all the items in a shopping cart and show them to the user before submitting the form. In fact, almost all shopping cart details can be stored on the client and sent to the server only at checkout.
Currently, this process is implemented with JavaScript; but JavaScript is ugly and hard to maintain. Adding calculation fields that depend on the content of other fields enables a more declarative approach. Furthermore, these fields can be pure output fields that only the client sees. The server never needs to see them. For security, it recalculates everything based on the independent data the client enters. Dependent data is left on the client where it belongs. This approach neatly avoids any chance of a server programmer opening a security hole by depending on client calculations that can be subverted.
XForms is designed to work in multiple environments for users with widely varying abilities, both technical and personal. It achieves this goal by separating the form data from the form presentation, thereby enabling many different renderings of the same form to serve the needs of different users.
This approach requires a significant shift in how you think about and design software. It's similar to moving from presentation-based markup in Word to semantic-based markup in XML. In the programming domain, it's similar to moving from an imperative language such as the Java™ language to a declarative language such as SQL. When you're designing XForms, it's necessary to think about the information you want to get from the user rather than what the form will look like.
I'm not sure this style of form design is any harder than traditional visual layouts, but it's more indirect and it's unfamiliar to most Web designers. It definitely requires some getting used to. The additional layer of indirection may not be worth it for simple applications with a single delivery mechanism. However, for more complex applications, it shows real promise to improve accessibility, localizability, security, robustness, and other desirable characteristics.
Learn
- Read "Introduction to XForms, Part 1: The new Web standard for forms".
- XForms Requirements offers the original explanation of why XForms were needed.
- The XForms Working Group Charter presents the original, official goals of XForms.
- Read Wikipedia: XForms: a customarily excellent entry.
-
Wikibooks has a section on XForms: Tutorial and Cookbook with new information updated frequently.
- The book
XForms Essentials (Micah Dubinko, O'Reilly, 2003) explains how to create XForms.
- The XML technology
zone provides hundreds of articles about every aspect of XML development.
-
developerWorks technical events and
Webcasts: Keeping you
current.
Get products and technologies
-
Get MozzIE, an open-source control that allows you to render XForms in IE.
Discuss
- developerWorks
blogs: Get involved in the developerWorks community.
Elliotte Rusty Harold is originally from New Orleans, to which he returns periodically in search of a decent bowl of gumbo. However, he resides in the Prospect Heights neighborhood of Brooklyn with his wife Beth and cats Charm (named after the quark) and Marjorie (named after his mother-in-law). He's an adjunct professor of computer science at Polytechnic University, where he teaches Java technology and object-oriented programming. His Cafe au Lait Web site has become one of the most popular independent Java sites on the Internet, and his spin-off site, Cafe con Leche, has become one of the most popular XML sites. His books include Effective XML, Processing XML with Java, Java Network Programming, and The XML 1.1 Bible. He's currently working on the XOM API for processing XML, the Jaxen XPath engine, and the Jester test coverage tool. He'll be speaking and listening at the XML 2006 conference in Boston in December.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
