Next-generation e-forms

Because Adobe’s solution leverages features that already exist in the free and widely deployed Acrobat Reader, its reach will exceed that of InfoPath, a product that is available only for Windows and is bundled only with the enterprise edition of Office 2003.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Try Sun servers, workstations and storage products free for 60-days. Sponsored by Sun Microsystems

Adobe’s PDF-oriented solution also trumps Microsoft’s in terms of its fidelity to printed forms — but a form’s appearance and its capability of capturing data are really two issues that need to be teased apart. A printed form is often the best solution for reviewing, signing, and archiving, but the digital-paper version of that form, onscreen, is not clearly the best solution for interactive data-gathering. Users of tax preparation programs such as Intuit’s TurboTax or H&R Block’s TaxCut, for example, want to be able to print pixel-perfect tax forms. But few would prefer to interact with literal representations of those forms. We value the dynamic, spreadsheet-like, wizard-assisted experience that the tax programs provide.

Digital paper is not a medium that easily supports implementation of these dynamic behaviors. This will be a major consideration for developers who pursue Adobe’s solution. It’s fundamental to InfoPath, for example, that documents can have multiple views, that regions of documents can grow on demand, and that repeating elements can appear and multiply. The Acrobat display engine wasn’t built to do these things. Adobe’s Myers admits that some capabilities available in the Forms Designer — notably, repeating elements — won’t initially be supported in Acrobat. “On the PDF side, we have a ways to go still,” he says. “But when you look at future versions of Acrobat, that’s the direction we’re moving.”

Introducing XForms

Any e-forms application that can absorb an XML schema and emit schema-valid XML data is guaranteed to be able to exchange data with XML-aware back-end systems and with other XML-aware clients. But whereas portability of data is rapidly becoming a given, portability of business logic and user-interface behavior is not.

XForms, which can be thought of as HTML forms on steroids, specifies a processing model and set of user-interface controls that are device-neutral and platform-independent. So a form’s interactive behavior and to some extent its business logic can be made portable, too. A key aspect of that portability is the relationship of XForms to its so-called host markup language. In one implementation, the XML syntax defining an XForms form might be embedded in a Web page, using HTML as its host language, and a list of choices would be rendered as an HTML pick list. In another implementation, the same form definition might be embedded in a smartphone application, using VoiceXML as its host language, and the same list of choices would be rendered as on a voice menu.

Another host language is XFDL (Extensible Forms Definition Language), which predated and inspired XForms and is now the foundation of the PureEdge Solutions’ e-forms products. According to John Boyer, the PureEdge senior product architect who co-wrote the XFDL specification, it has two features that make it especially appealing to enterprise developers. First, its built-in compute engine supports a highly declarative approach to business logic, minimizing the need for procedural scripting. Second, it supports flexible and granular security policies. Parts of documents can be signed separately by different people, a key requirement for complex workflow currently met neither by Acrobat nor InfoPath. The only implementation of XFDL is PureEdge’s, but Boyer is a leading contributor to XForms 1.1 and hopes to infuse it with these ideas.

Cardiff is another leading e-forms vendor with a strong hand in the XForms process. Micah Dubinko, principal software engineer at Cardiff, co-edited the XForms 1.0 specification. Cardiff’s XForms implementation, he explains, is “a generator, not an engine.” CTO Mark Seamans elaborates on the point: The company’s LiquidOffice e-forms offering, he says, includes “a universal design environment that’s publish-agnostic.” A form designed in that environment can currently run in InfoPath or Acrobat and will also be able to run in an XForms-based engine.

One advantage of this approach is portability of design effort. “An enterprise could invest three man-years in mouse clicks and drag-drop in InfoPath or the Adobe designer,” Dubinko says. “Cardiff wants to get you off that lock-in path.” Another advantage, specific to XForms, is the ability to target small-format devices — although that has not yet been proved.

Here’s the bottom line if you’re starting a new e-forms project in early 2004. InfoPath is a fine solution when users run Windows, can be expected to install InfoPath, and don’t require interactive digital paper. If you need to leverage Acrobat for one or more of these reasons, you’ll have to wait a while to try out Adobe’s Forms Designer. While waiting, you might want to evaluate Cardiff’s LiquidOffice as means of designing forms that play in Acrobat. If your requirements include complex digital signature scenarios supported neither by InfoPath nor Acrobat, have a look at the PureEdge suite. Finally, if you’re burning need is to build forms that adapt to a range of devices, you’re out of luck. The industry is still figuring out how to do that.