Copyright 2006 Robert J. Glushko
The "thin" browser platform freed developers from having to develop "thick" applications that needed to be installed and supported on every user's computer
Early versions of HTML were designed to support structured and hyperlinked narrative document types that were otherwise static with very limited display control
CGI, CSS and HTML forms were introduced for more interactivity, layout control, and transactional content
Java applets, Flash, DHTML, Java/VBScript, Swing etc. emerged as (often proprietary) alternatives to HTML to build more complex applications
These are sometimes called "rich" or "smart" client application platforms but they are now once again "thick" as well because they all require substantial client-side software (either standalone or as a browser plug-in)
XFORMS support in browsers to enable client-side validation and XML data interchange
Browser support for building UIs from XML specifications (XUL in Mozilla, XAML in future IE)
AJAX (asynchronous Javascript, eliminating full-page refresh and enabling much finer-grained interactivity)
Other proprietary platforms becoming "XML-ified" to enable web services and interoperability FLASH + XML
The standard web browser is a "thin" client that becomes "thick" with plug-ins that provide capabilities for enhanced interaction, client-side calculation and validation, etc.
These improved capabilities make it a "rich" client
The dilemma for web application developers is whether to rely on the standard and ubiquitous/universal client of the browser or to take on the problem of installing the "thick" client into the browser
So the goal is "rich" capability in a "thin" client -- or finding ways to eliminate the problem of installing and managing the required plug-in
are "Active"
are "Intelligent" -- "An Intelligent Document is a dynamic document that looks like a paper document and is easy to use" [Adobe]
are "Rich"

Combine information with the processes that surround it
Embed processes such as retrieval, data acquisitions, transactions, workflow, or archiving in the document itself
Are highly structured, yet are capable of changing their structure and presentation "on the fly" for different users, contexts, or uses
Become the de facto interface -- the gateway -- into the multiple applications that are related to the information
(In IDC article) An aircraft maintenance manual that self-updates with approved changes from multiple component vendors as updates are made to components and repair processes
A "graduate student universe" document that ...
A professor's "bio-bib" that ...
The proposal and bid document for a construction project that tracks the progress and costs during the project...
An insurance claim that combines information from the claimant, agent, adjustor, and vendor...
Many of these examples describe "active documents" that contain a mixture of narrative and transactional content
Most platforms for model-based applications are form-based and targeted toward transactional document types
"E-book" readers are a notable exception, designed as platforms for narrative document types to provide "book-like" display and interactive functionality
The simplest case of structured publication is publishing a single document in a way that lets the user interact with it by exploiting its (content) component structure
Many e-book platforms exist, and many have adopted XML formats (native or interchange) with Open eBook (but not all of them)
E-book readers differ in how much structural and presentation fidelity they enable and in functionality that "goes beyond the printed book"


(from E-Forms for E-Gov Pilot Team Final Report, Draft 09/29/2003 - http://www.fenestra.com/eforms/deliverables/final_report.htm)
Authoring-- designing the form's presentation, content, structure, and behavior
Generator--generating the form from existing metadata, like an XML schema
User Agent--UI that presents the form so that a user can fill it out ("creating the response dataset")
Web Broker--transforms the form into HTML for browser user agent
Catalog--library for forms
Schema Registry--library for metadata components or schemas from which forms can be authored / generated
Submission Server--receives response datasets and then stores, routes, and transforms them
Authentication --checks the respondent
Workflow--for choreography of forms
Absolute--ensures device-independent typographical fidelity
But everyone thinks the solution is the vendor-specific (almost) approach of using PDF!
A vendor-agnostic, device-independent approach is possible but substantially more difficult because you need both layout and semantic expertise
Relative--when fidelity isn't required
XForms is a new W3C Recommendation that separates the component model from a user interface model that uses "form controls" that label the input and output in a device- or style-independent way ("select one" vs "radio button")
This approach creates maximum flexibility in binding a user interface to a logical form and is essential in enabling accessibility
In contrast, other e-forms user agents do not separate a content layer from a presentation layer
Organizational agility is enhanced by controlling business processes at the document level
Users frequently need to work offline when filling in electronic forms
Users prefer electronic forms that resemble the printed form that it replaces or complements
Users expect a record of their electronic transaction that resembles the printed form that it replaces or complements
An application that everyone already has
Web browser (IE 84%) and Firefox (10%) are the dominant web clients today
Adobe likes to promote the fact that there are half a billion PDF-capable web browsers out there (the Adobe viewer runs inside the Web browser, renders the PDF form inside the Web-browser window, and manages the user's interaction with the text boxes, lists, and buttons, etc. that are on the PDF form)
Most recent versions of Adobe reader (6+) are capable of being "turned on" to expose hidden functionality, enabling users to interact with "intelligent documents"
LiveCycle Reader Extensions: http://www.adobe.com/products/server/readerextensions/overview.html
"Leveraging the richness of PDF with the power of XML"
XMP (extensible metadata platform) built into all Adobe applications (Photoshop, Illustrator, Acrobat)
XFA (XML forms architecture) is more relevant for model-based applications; the appearance and behavior of an XFA-based form is dictated by an XML data structure inside the PDF file
Collaboration - control for multiple authors / roles
Process management - automation of document-based workflows
Control and security - ensure authenticity, content integrity, and confidentiality ("persistent control," "deter phishing and forgery")
Document generation - extract and embed information from enterprise applications
"The front end for an organization's electronic processes"
Workplace Forms are written in XFDL, which goes beyond XFORMS to support enterprise application requirements like multi-page forms, attachments, security, auditability
Preferred deployment is with the rich client IBM Workplace Forms Viewer, but Forms Server can support HTML forms
IBM's philosophy and implementation differs significantly from Adobe's