The Structural/Visual Component

Perhaps the most obvious component of a UI is the way the UI is presented to the end user. For most applications, it includes menubars, toolbars, icons, and other such things, and is referred to as a GUI. On most windowing systems, there are guidelines to the overall GUI structure (often called look and feel guidelines).

The important thing to note about GUI's, is that they are intrinsically hierarchical, because there is an obvious containment relationship that can be reflected as a tree. In most modern GUI's, the windowing system supports the hierarchy directly, with windows that can be nested within one another[5].

Take the following example:

Example of a GUI

This GUI is made up of a number of display regions (windows) nested inside one another. Ignoring the physical implementation of the GUI, one can come up with a logical description:

There is a top-level window that contains a menubar, followed by a toolbar, followed by two windows, side by side. One is a TOC window, and the other, a text window. Those two windows are separated by a bar used for changing the amount of space each takes up, and each has a scrollbar. A search sliver follows these two windows.

The fact that a succinct description of the GUI can be made so easily, and that the description uses purely declarative statements, is important to note, as this opens up a realm of possibilities.

The Behavioral Component

A very important part of UI's is how components interact with one another and with other parts of a system. This is often referred to as the behavior of the application.

At first, it would appear that there is no way of defining behavior other than by writing code, but there are four observations that can be made:

• Each UI component has a limited number of operations that are applicable to it, so the problem is somewhat constrained.
• Programming can be looked upon as a language creation task: each object function etc. a programmer creates is a new word that can be used for describing a problem and/or it's solution. By starting with a suitable predefined vocabulary of sufficient size, programming can be minimized (because there is no pressing need to add new words to the language).
• Each behavioral interaction can be regarded as causing a state transition in one or more components[6].
• The level of behavioral specification required amounts to something similar to either a property change or a method invocation (where a property change can be seen as calling a method for that purpose). Method calls will contain most of the actual processing, and will perform the actual state change (this implies that each UI component have a well-defined API, and that there be a way of invoking methods dynamically).

These observations lead to the conclusion that it is indeed possible to define application behavior in a purely declarative manner. This conclusion is certainly not intuitive for most programmers[7], which is why there are few environments that attempt to exploit this.

What is less intuitive is that any declarative statement can also be represented in XML.

It is reasonably well known that declarative programming is much faster, more reliable, and maintainable than procedural programs, so any environment that exploits the ability to declaratively define application behavior, is likely to reap significant benefits from it (or more correctly, people using the tool will reap the benefits). However, environments that provide such benefits by exploiting declarative behavioral definitions are scarce.

The WWW, where scripting prominence is rising at the same rate as site maintenance costs, represents a perfect opportunity for exploiting the above, especially if XML is used to represent the declarative definitions.

Java Beans, Visual Basic, CORBA and COM

Most modern RAD (rapid application development) environments are really GUI development environments, because they do little to help develop the application logic itself, and instead focus on GUI building and project management. Such evelopment environments generally provide the following capabilities:

• A palette of predefined components, and a drag-and-drop, property-editing paradigm for development.
• An interface for grouping files and other resources into a project.
• A way to generate skeletons for handling property changes, events etc., and a way for managing the code placed into the skeletons by developers.
• A debugging environment allowing programmers to debug their procedural programs.

A typical example (the Visual Basic Editor from MS Word) is shown in the following figure.

Visual Basic for Applications Development Environment

Most basic GUI-builder interactions with the components take place via property editing. Programmed blocks of code that respond to events (one can look at these blocks of code as properties of the object as well) handle behavior (such as calling out to ODBC to get the value for a property) that cannot be described by properties alone.

This paradigm is widely accepted by developers as being powerful and easy to use. The most important aspect of this paradigm that there is a predefined set of components that each consists of a look and feel and a set of properties.

JavaBeans, one of the new and wildly successful Java technologies from Sun, is based on a convention for object interfaces. Like Visual Basic objects in the above example, a JavaBean is a component with a set of properties that can be manipulated. JavaBean technology standardizes how an application can get information about the properties (using introspection and special interfaces), and how properties can be manipulated (through get/set method pairs and property-specific editors). Programmed behavior is added either through action handlers, or in the implementation of the get/set methods.

JavaBeans were originally widely used for GUI objects, but recently, Enterprise Beans have gained wide acceptance. An Enterprise Bean is simply a JavaBean that wraps up some part of a business in a bean interface (for example, a legacy database might be exposed as an Enterprise Bean). Enterprise Java beans aim at tackling many of the problems CORBA and DCOM are aimed at.

CORBA and COM are two object technologies that allow programmers to specify the interfaces[8] of a component, and provide a cross-language framework for manipulating objects via the defined interfaces[9]. They allow one to define both attributes (properties), and methods, using an Interface Definition Language, or IDL. These technologies only specify the interface of a component, not how it is implemented. They can be seen to complement JavaBeans, in that JavaBeans basically conform to a 'bean interface specification', which could be defined in either CORBA or COM. A JavaBean is more than just interfaces however: it is an object, and as such has code implementing the interfaces.

Under Windows, COM objects are used for much the same purposes as JavaBeans: COM provides a basic interface that objects must conform to, and provides a way of asking objects what other interfaces they support. This is put to good effect in many of Microsoft's object technologies such as ActiveX and OCX controls, where the normal way of interacting with the objects is through a GUI development tool. Such tools can use COM to discover the methods and attributes of an object at runtime, and hence can be written independent of the set of objects they will deal with (Bean editors provide the same capabilities for Java).

CORBA offers a superset of COM functionality in a platform and language independent environment.

All these technologies were (and are being) developed with the express purpose of providing a simple, flexible way of defining objects and their properties, and a way of manipulating the properties of instantiated objects[10]. All also provide some way of adding programmed behavior to objects.

Serialization and Object Instantiation

The properties of an object represent its state. By retrieving the values of all properties, and creating a serial representation of them, an object is said to be serialized, and its state is saved. An object can be serialized to a file for persistant storage, to a network connection for object migration or communication, or to any other media desired.

An object can be deserialized, meaning that a new object is created (instantiated), and the serialized properties are used to set the values of the properties in the newly instantiated object. The newly created object is a clone of the original, and in some cases, both the original and the clone can coexist.

Note that this is explicitly different from object migration, where an object is serialized, but once deserialized, takes on the identity of the old object (the old object is destroyed). With object migration, it is an error for both the original and deserialized objects to exist in the same application scope, though with pure serialization and deserialization, this is not necessarily an error (in general it is, but in some cases, such as cut buffers, it is not).

Serialization and deserialization are depicted in the following figure.

Object Serialization and Deserialization

Note that only the properties of the object are being serialized, not the objects' code (though in a pure OOP system, the code would be a property of the object itself, allowing for true object migration).

The single most difficult thing about object serialization is that many objects have other objects as a property, so the entire object hierarchy needs to be serialized, and some ordering maintained so that deserialization can be performed in a stream-like manner. In some cases, the objects do not even form a hierarchy, and instead form a graph, further complicating serialization algorithms.

Serialization can be used for individual objects, or for an application, whereby the entire state of an application can be saved and restored at some point in the future. [11] This is an important point that has far-reaching ramifications.

Using XML for Serialization

An obvious application of XML in the above is as a replacement for the IDL (Interface Definition Language) used by CORBA and COM. This leads to an interesting form of literate programming for interface definitions, and has been put to good use in the W3C DOM, where the HTML documentation, CORBA IDL, and JAVA and ECMAscript bindings are generated from the XML source[12]. A number of efforts are underway, some within the OMG (the group managing CORBA development), to standardize an XML mapping for IDL, and for using XML in interface repositories.

A less immediately obvious[13] use of XML is as the serialization format used for data interchange between applications. RPC and various other data interchange efforts all have an "on the wire" format which is used for communication, with objects being serialized into and deserialized from it (usually this is called marshalling in this context). XML can be used for as the standard "on the wire" format (which is what WebMethods tools do).

For example, the logical description of a UI given earlier could very easily be rephrased (serialized) using XML, as the following example shows.

<UI>
  <MENUBAR>
     <MENU>
        <ITEM>Open</ITEM>
        . . .
     </MENU>
     . . .
  </MENUBAR>
  <SPLITPANE GEOM="30%,70%">
    <TOCVIEW/>
    <TEXTVIEW/>
  </SPLITPANE>
  <TEXTFIELD/>
</UI>

One could just as easily serialize any object into XML: XML is rapidly gaining a foothold as part of a middleware layer between legacy enterprise information repositories (such as mainframe databases) and the WWW, which is the first step in this direction.

Toolkits for object serialization to XML are also beginning to appear (Coins and Koala being two). In such situations, the serialization picture changes slightly to become:

Serialization/deserialization using XML as the data format

This is obviously not a massive departure from existing practice (just a simple change in serialized data format), and so object serialization into XML should become commonplace over the next few years. This is especially true given the capabilities of JAVA, CORBA, and COM for introspection, which allows generic serialization engines to be developed.

However, when using XML simplistically as a serialization format, one of the following difficulties is likely to occur:

• Hard coded serialization — in effect, each object would have a special constructor written for it that understands XML instance syntax (schema) specific to the internals of the object. Any change of property lists will require changing the serialization code. This is basically the approach that Coins takes.
• Unintelligible XML instances — in order to develop a generic XML serialization engine, object names, property names, and XML instance syntax in general, will reflect the internals of the object being serialized. In effect, this will render it meaningless to humans, and difficult to reuse for anything other than deserialization.
• Object system dependent — serialization as used above, tends to be object system dependent, again hindering reuse.
• Media dependent — reflecting the object system dependence, the serialized data is also generally media dependent, making it hard to retarget.

These all basically reflect the fragility of simplistic serialization: small changes can break many parts of the system, and it can be very hard to recover from the mistakes, or to repair such serialized instances.

For example, a simple serialized EDI message might look like the following XML fragment.

<code-list>
 <desc>
   <date>Apr 09,1998</date>
   <time>08:00</time>
   <source>ISO 4217</source>
   <title>3 Character Country Codes</title>
   <usage>ASC X12 D.E. 100 - Currency Code</usage>
   <author>FORESIGHT Corp.</author>
 </desc>
 <codes>
   <code><name>ADP</name><defn>Andorran Peseta</defn></code>
   . . . . . . . . . .
   <code><name>AOK</name><defn>Angolan Kwanza</defn></code>
   . . . . . . . . . .
   <code><name>ZWD</name><defn>Zimbabwe Dollar</defn></code>
 </codes>
 </code-list>

As most people could point out, this is fine for certain cases, but is certainly not the most flexible because much of the information is left implicitly defined. Indeed, there are a number of ISO, and ad hoc working groups, whose sole purpose is to provide an XML syntax for EDI messages that is easy to process by humans and machines.

The Next Step

To get around the problems above, a degree of extensibility and intelligence can be introduced into the deserialization engine, in effect creating a data-driven deserialization engine.

Serialization and Data-driven Deserialization

By adding the extra level of intelligence (the data-driven deserialization engine and deserialization specification) the following benefits, among others, can be accrued:

• Instance syntax independence — the format used for serialization can be anything at all, so long as a deserialization specification exists. Note that the deserialization specification is data, and so no code needs to change even in the face of radical changes to the serialization format. The deserialization specification is necessarily tied to a serialization format, however.
• Intelligible serialized data — a direct benefit of the above is that serialized instances can be intelligible to humans, and indeed could be documents, rather than serialized objects. As such, a document could be used to instantiate the UI used for interacting with it, based purely on the structure of the document itself (document as UI). This brings a new dimension of reusability to documents, and makes the notion of document-centric application literally true.
• Object system independence — a given serialized instance can be instantiated using different object systems. For example, a serialized instance could be instantiated using CORBA, Java, or COM.
• Media independence — a given serialized instance can be instantiated on vastly different media by using a different deserialization engine, different deserialization specifications, or a combination of both. For example, an object could be instantiated as a button in Java, a button in HTML (using DHTML), or as a voice selection for aural readers.

These benefits to object instantiation are basically the same as those that generic markup brings to the world of documents.

Instantiating XSL Beans

As discussed earlier, the process of instantiating an XSL bean is effectively that of a data-driven deserialization engine, or of an XSL processor with a (possibly) optimized FOT processor chain.

Object System/Media independence

A given XSL processor might be implemented such that it can instantiate arbitrary objects (very likely with COM, CORBA and/or Java), making it possible to instantiate an XSL Bean in a number of different ways. For example, in the following diagram, a <list> element is being instantiated as an object (for example, a ListBox JavaBean) or as a <ul> list in HTML.

XSL Bean Processing and Instantiation Model

It is equally possible to produce a high-quality formatted version for print, and in a web delivery component it should be possible to specify whether a UI should be sent to a browser as a set of applets, or in DHTML.

As such, an XSL Bean is best described as XML instance data with one or more associated XSL stylesheets for controlling the instantiated form. The ability to support multiple media and looks and feels through style selection is a key differentiator.

Providing an XSL Bean Engine

Assuming an XSL processor written in Java, the creation of a generic XSL Bean engine capable of instantiating arbitrary objects is fairly trivial. In Java it is possible to instantiate classes by name: using XML namespaces, and possibly other hints in the stylesheet, the XSL processor can determine the name of the flow object it wishes to instantiate, and do so. The flow objects instantiated could literally be any Java object that conformed to the interface.

It is possible to do something very similar using CORBA as well.

The only problem with instantiating objects by name is that the operation is slow. For performance-sensitive applications (such as a stylesheet editor), it is probably unacceptable to incur this overhead; so application-specific instantiation code might be needed for an otherwise generic XSL engine (i.e. hard coding the FOT vocabulary).

Note that an XSL Bean engine could be used over and over again within applications. Almost all of the application GUI's could be built using an XSL Bean Engine, and they would be available as Java applets or applications, or as WWW-based GUI's. Forms based editing can be seen as a useful extension of the basic XSL Bean environment (in effect, this is distributed XSL Bean authoring).

Providing a Development Environment

XSL Beans development environments are discussed in detail elsewhere, but there are basically three choices :

1. Buy it — a development environment could be purchased from somewhere, and modified to suite. The probability of finding a suitable development environment for sale is small, and even if one were found, the probability that tailoring it would prove cost effective is low.
2. Build it — obviously, one could build a development environment given suitable resources.
3. Integrate — here some application-specific JavaBeans that could be used in JBuilder, Visual J++ etc. would be written. Those environments would be used to create an applet (i.e. perform the layout), entirely using Java. A tool would be provided that loaded up the applet, and then serialized it to XML. When using application-specific JavaBeans, greater control over the serialized format can be gained (especially if all Beans used were from one place). XSL bindings for the serialized form would still need to be developed.

The author's personal preference is to develop a native XSL Bean environment.

Providing a Standard Set of XSL Beans

In both of the likely ways a development environment can be supplied (building or integration), JavaBeans would be used during the actual drag and drop layout editing. As such, the task of providing a standard set of XSL Beans can be broken into two major phases:

• Determine the set XSL Beans that need to be provided (ListBox, Menu, TOC, etc. etc.). This requires a substantial amount of analysis of the reference applications for the technology. The task of deciding exactly what set of XSL Beans needs to be supported belongs to product management, or the market.
• Provide JavaBeans and sets of XSL stylesheets that can be used to instantiate the XSL Beans. The main issue here is making sure that the beans work correctly in multiple environments (Java application, Java applet, DHTML).