Build Rich, Thin Client Applications Automatically Using XML

Build Rich, Thin Client Applications Automatically Using XML "Much of the innovation in programming in recent years has involved loose coupling. The invention of database driver methodologies such as JDBC and ODBC led to applications being loosely coupled with their back end databases, allowing best-of-breed databases to be chosen—and swapped out when necessary—without any ill-effect on the user interface. In the bad old days when the user interface was part of the data engine, an update to the database would require an extensive rewrite of the GUI.
Similarly, the decoupling of data and presentation in HTML—by using XML for the data and XSLT for the presentation of data—has led to much innovation and flexibility, not least of which is the ability to deliver a document as data in XML and deliver custom styling for that document with different XSLTs.
The next big trend in decoupling appears to be separating the user interface implementation from the user interface definition. There are countless initiatives, both open source and commercial, that will have at their core this very principle. The next big revolution in the desktop Windows operating system from Microsoft, codenamed Longhorn, is perhaps the most notable of these. With this type of decoupling, when a user interface is defined in a document such as XML, users would not have to download and install their GUIs; they can simply browse them as easily as they browse Web pages. A runtime engine would be present on the desktop, and servers would be able to deliver the GUI to the browser with an XML document.
This will be huge for the corporate environment where at present, rich desktops are difficult and expensive to produce and maintain. Corporations are necessarily paranoid about allowing users to download and install binary files, and in general block users from doing this. The only options are to build a rich interface in HTML, or to build Windows applications and install them using a CD. With this type of decoupling, when a user interface is defined in a document such as XML, users would not have to download and install their GUIs; they can simply browse them as easily as they browse Web pages.
Building rich applications in HTML or DHTML is feasible, but suffers from a number of drawbacks. First, an application written in these languages is interpreted by the browser, which isn't optimized for running applications. Browsers are of course designed to render content; having scripted, parsed applications run within their context is an afterthought, and as such is very slow. Second, once the application is designed and coded, should you want to present a similar application to another customer—branded and designed according to their styles and tastes or to coordinate with their existing systems—a rewrite of the application is usually necessary. The world is becoming used to XML driving HTML, with XSLT stylesheets to brand the data differently for different users.
So why should more complex user interfaces be any different? They shouldn't, and that's the philosophy behind these new initiatives, including Longhorn, which will have its user interfaces defined using a language called XAML (XML Application Markup Language). In short, if a user interface is defined using XML as opposed to programmed using something such as C# or Java, then a runtime engine can parse it and render it on screen. Hooks within the XML could link to server-side applications that process information."