Adobe, InfoPath, Xforms, and eForms
November 7, 2003
The lastest version of The Gilbane Report contains my initial analysis of the recent changes in the eForms space, including, notably, the release of InfoPath and the approval of Xforms as a W3C recommendation. I have never taken a keen interest in the eForms world, but the vendor announcements and the standards efforts are important.
To quote briefly from the article:
Electronic forms (eForms) have always represented a significant piece of the Enterprise Content Management puzzle. On one end of the marketplace, eForms have been implemented to replace traditional paper processes, such as in government and paper-intensive industries such as financial services. In a number of other applications, such as Web Content Management, eForms are the de facto user interface for such tasks as content entry, editing and system administration.
As eForms have proliferated in both of these types of applications and others, the functional and architectural requirements for eForms have grown. Where early eForms were successful merely for capturing and perhaps storing data, it didn’t take long for developers to want to manipulate and work with the captured data. On the end of the market where dedicated eForms tools were being used to automate paper processes, such development typically involved working with the proprietary data structures and programming interfaces of the eForms vendor. In applications such as Web content management, the functionality and architecture of eForms were bounded mainly by HTML and related technologies such as JavaScript. As organizations have moved toward application server-centric architectures such as J2EE and .NET, both the proprietary approaches and HTML-based forms have failed to keep up.
Posted by Bill Trippe at November 7, 2003 8:11 AM
