ake a look at the applications you deal with on a regular basis. Regardless of the platform or GUI that you use, or the programming language used to create them, there's a certain innate commonality to applications: areas where you enter text, buttons (always buttons), menus, scroll bars, sliders, grids, trees, panes (or pages), and so forth. Certainly there are exceptions; graphics programs such as Photoshop or 3D Studio have much more sophisticated interfaces, and games are fundamentally all about interface. But for most business programs, such as accounting packages, word processors, statistical analysis applications, or a wide range of other programs, you'll find a common set of abstract "components" that provide the bulk of interface functionality. In many cases these components also perform a significant amount of the intermediate processingcommunicating directly with databases, setting internal variables to the application, persisting content, and so on.
If you think a bit more about such applications you also begin to see other pieces of commonality. Starting roughly fifty years ago, programmers realized that by creating an application that looped continuously, the application could retain its own internal state, working in "user" time to accept input interactively and generate output without terminating. This idea caused the shift from batch mode to interactive mode programming that underlies every windowed operating system today. Admittedly, most modern applications subscribe to a thread manager rather than creating a (system-locking) infinite loop; however, if you delve deeply enough into that thread manager, the loop is there, figuring out which thread to run at each successive pass.
The modern version of this application loop is called an event loop, named for its role in managing not just threads, but also the events that are passed from the system to various objects within the interface. Events that are not intercepted by some object within the event loop are recycled back to the system, which can discard them or handle them generically.
Event loops make it possible to load and maintain an internal state within the application. That state may be simply the contents of the visible form elements in the application, but more typically, the state is a separate model of which the visible interface is simply a reflection. When you load a file into the application, you are generally loading the model. Similarly, saving the file persists the model in a format understandable to the application.
HTML, as it exists right now, is at its core a batch documentthe HTML content that describes a form is read by a browser and rendered as a Web page. In the absence of a scripting language, the form elements themselves are almost completely staticthey cannot validate content, they do not interact, and most importantly, changing their states only sets the values of each controlthere's no underlying background model. You can add interactivity via scripting and working with the HTML DOM, but that's not always portable between browser implementations, and still involves sending the interface representation to an external client, losing state the moment the client replaces the page with a new one.
If you take a look at a typical XForms viewer, you'll find that it gives you much the same kind of structure as any other application framework does: moving from a batch to an interactive programming mode. Implementations differ, but all XForms viewers preserve and update internal state for the application.
The idea here is pretty simplethe View, or user interface, provides a set of controls that give the "public" face of the application. The only way you can interact with that XForm is through its public face. Every time you load the form, enter a word into a text box, move a slider's thumb, or select an item from a drop down list, you change the state of a control, which in turn launches an event notifying the system that a change has taken place. You can then define actions (akin to event handlers) that occur whenever the event is fired for that particular component to update the internal model. You can also bind events to the model so that when a given value in the model changes, it forces an event to be launched that can be caught elsewhere.
If this sounds a lot like traditional event-based programming, that's because it is. The only difference is that the event handlers, the event notifiers, and everything else are built with XML; you handle processing with XPath expressions, describe the model using XML schema, and fire events using the XML Events architecture.