Daniel Rivers-Moore

1. What is a software application?
   1. The nature of the user interface
   2. Principles of application design
   3. Minimising the number of distinct data structures
2. Building an application
   1. Datasets and items
   2. Logical forms and their presentation
   3. Using XPath statements to identify information sources
   4. Data validation
   5. Driving the application logic
3. Conclusion
4. Acknowledgements

What is a software application?

A software application is essentially a tool for transforming one form of information into another, with or without a degree of human intervention. In this sense a software process is highly analogous to a business process or an industrial process. All three transform inputs into outputs of (hopefully) higher value. Such processes can be defined procedurally – by specifying how they are carried out – or declaratively – by specifying what should be transformed into what.

The historical evolution of software has been a steady movement from more procedural to more declarative approaches. Object orientation represented a significant step towards a more declarative paradigm for software application design. XML makes possible the next logical step in this direction.

There was a time when IT was known as DP. At a time before graphical user interfaces and hands-on computing, the role of the computer was essentially seen as being one of transforming different data structures into one another as the information they represented moved through the business process.

Today, humans are much more intimately involved in the information flows. The desktop PC took data out of the centralised data banks and put it within reach of office workers sitting at their desks. The home PC, the Web and the Internet-enabled mobile phone continue this trend and bring information and data to our fingertips and into every corner of our daily lives. But at root, what is happening is still the same. Information is being encoded through different data structures, and moved around the world, being transformed as it goes according to the needs of the business or of the individual user.

The nature of the user interface

Some of the data transformations involved in the coming generation of Internet-based distributed applications will be hidden from the user. They may happen on Web servers, inside client PCs, inside a mobile phone or a household appliance – the user really doesn’t care. Other transformations will happen in a hands-on manner, with the user intimately involved through some kind of user interface.

The browser is likely to become the ubiquitous user-interface host on the desktop or laptop PC, but other user interfaces will be provided through palmtop devices, mobile phones, TV sets with their remote controls and a host of other appliances ranging from motor-car dashboards to microwave ovens. The requirement on user-interface design is therefore not to create a dedicated application with its own graphical user interface, but rather to create ways of transforming whatever data the user needs to interact with into XHTML, WML, or whatever XML flavour is required for the particular interface device being used.

In order to maximise flexibility, and the possibilities of reuse of code, it is important to separate out logically distinct aspects of information, and hence separate out the transformations involved so that only one logical transform is performed at a time. It is also important to separate the structural aspects of the user-interface design, which will be the same whatever physical device type is being used to host the interface, from the purely presentational aspects, which will be specific to a particular kind of device.

XML itself is based on the principle of separation of content from presentation, so this approach finds a natural fit in the XML paradigm. And the XML transformation-specification language, XSLT, will play a crucial role in this aspect of application design (as indeed in several others, as we shall see shortly). Using XSLT transformations at the point of delivery makes it possible for the application designer to consider the logical structure of the user interface separately from its presentational aspects.

Principles of application design

As part of the European XML/EDI Pilot Project (a collaborative project carried out during 1999 and part-funded by the European Commission through its ISIS programme) the following design principles for Internet-based applications were identified:

The separation of logical user-interface design from presentation, which we discussed in the previous section, is one aspect of design for maintainability and extensibility that will be essential in the brave new world of Internet-based computing. It is an example of the third principle above, namely decomposing the complexity of the requirements into a sequence of data transformations. By carrying out two transformations instead of one – first from the interchange format to the logical structure of the user interface, then from that logical structure to its specific manifestation in the interface device being used – the application becomes far more comprehensible, extensible and maintainable.

Minimising the number of distinct data structures

Let’s look now at the next principle – minimising the number of data structures used by an application.

A little thought will make it clear that there is in a sense a required minimum number of distinct data structures required in any Internet-based distributed application:

To summarise, an Internet-based distributed application will need, as a minimum, 2 to 6 distinct kinds of data format, namely:

Previous

Table of Contents

Building an application

I’d now like to take a look at how the application-design principles listed above were applied by the European XML/EDI Pilot Project to build a prototype application – a Transport Firm Booking application based around established EDIFACT messaging protocols for container transport operations.

Based on the first two of our guiding principles, the application is built using XML for all the data formats it required, and XSLT to define all the necessary transformations. This involved developing some general-purpose XML structures for the last three kinds of data format listed above. Let’s take a look at these now.

Datasets and items

In order to minimise the number of distinct data formats needed in its applications, the European XML/EDI Pilot Project developed a DTD for what it called Extensible Information Sets (XIS), consisting of Datasets and Items. This was used as a common supplementary data format throughout the application.

One of the requirements of the project was to build applications that allowed users speaking different languages to use the application interfaces. Thus, it was necessary to configure a given user interaction session for language, and this required a list of supported languages as a piece of supplementary data. This is how the language list looked:

This presents a Dataset consisting of Items of type “language”, each with a “sibling-unique identifier” (Suid) and a description.

By adding additional subelements to Item, richer structures can be handled. This approach was used for another Dataset consisting, this time, of the carriers that might be used to undertake the transportation operation:

Another powerful way to enrich these data sets is to provide multiple Description elements for any Dataset or Item. These can be qualified by language (using the xml:lang attribute) and/or by variant. As we shall see shortly, these Description qualifiers can be used to drive a highly configurable user interface.

Logical forms and their presentation

One of the requirements of the Transport Firm Booking application was to allow the user, once a carrier had been chosen, to enter details of the transportation operation he or she wants that carrier to perform. For a user seated at a PC with a Web browser, part of the data-entry form looks like this:

The way the first section of this form is encoded in the interface logic specification is as follows:

For a user with a mobile phone, the interface logic specification is unchanged, but the way it would be displayed might be quite different:

The HTML required to produce the first result, and the WML required to produce the second, are both generated out of the same interface logic data. It is important to notice that the words that appear on the form are not included in the interface logic specification. Instead, LabelRef and InfoSource attributes are provided. The LabelRef attribute identifies one of the Item elements in the Label Dataset which was introduced at the end of the last section. If you look back at the extract from that file, you will see that Label24 has a Full English-language variant of “Company name”, and a Compact English-language variant of “Company”. You will see that in the browser, it is the Full variant that has been used, and in the mobile phone it is the Compact variant.

The next section of the browser form has two text fields available for the user to input their name and email address. The interface logic data for this part of the form is very similar to the previous one. It simply uses different LabelRef and InfoSource attributes, and replaces the ReadOnlyData elements with Interface elements consisting of EditableField elements containing empty Value elements. When the user enters data into the field, the currently empty Value elements will be populated by the data entered by the user.

Using XPath statements to identify information sources

Just as the LabelRef attributes above referred to a Dataset of Labels, so the InfoSource attributes refer to a Dataset of Contexts. What is meant by a Context here is a specification of the place in the interchange format structure where the data in a particular field in the user interface comes from, and to which it is returned after it has been edited by the user.

Pursuing the example of company name, we note that the InfoSource for the company name in the example above is identified as “Context2”. Let us now look at the context.xmlfile, which contains the Context statements these identifiers refer to. As we have said, we are using a common data format for all supplementary data, so this file too contains a Dataset of Item elements, but on this occasion the Type attribute of the Dataset is set to “Context”. Here is the relevant extract:

There are two Items in this extract. Note that the second has a Datatype attribute of “email”. We shall return to this in the next section. For now, we’re interested in the first Item. What this tells us, in English, is that this field contains the carrier company name. What it tells the system, using XPath syntax, is that this piece of data is the content of the TextLine subelement of the Name subelement of the Party subelement of a PartyContactsGroup element, where the PartyQualifier attribute of the Party element has the value “Carrier”. And indeed, when we look at the XML file that was read by the system in order to generate this form and present it to the user, we find the following structure:

Because the words “The Universal Transport Co.” appear here in a context that matches the XPath statement above, these words are displayed in the user interface as the content of the relevant read-only field. This field is identified for the user by a Label drawn from the Description with the appropriate variant and user language identified by the LabelRef attribute in the interface logic specification.

It should be becoming clear how we can build up quite sophisticated and flexible application user interfaces out of this kind of simple structure, in an entirely XML-driven manner. I’d like now to take a brief look at data validation issues, then move on to the application logic aspect, before concluding.

Data validation

When the user presses the Submit button on the form, it might be necessary to check the validity of the data they have entered, before sending the data on to the next stage of the application (which may be local or remote). This can be done very effectively by associating a datatype with each data context, and defining rules for the validation of each datatype.

Let’s take the example of the carrier’s email address, which is identified in the interface logic specification above as belonging to Context3. We noted above that this Item has a Datatype of “email”. The application uses an datatype.xml file contains a Dataset of Datatype specifications. Here is an extract from that file:

The above structure specifies that the email Datatype is associated with a set of “validation” mechanisms. One of these validation mechanisms uses an “xslt” processor to carry out the validation. The specification for this validation process contains a set of tests that the XSLT processor can use to validate the content of any field that is associated with the email Datatype. Among these, the test called “test1” checks the data against the XPath expression “contains(Content,'@')”. We are also provided with an error message which will be displayed if this test fails.

When the user presses the Submit button, a series of XSLT transforms is triggered, which draw on the various data structures we have looked at, and which produce a new HTML display in the browser, which looks like this:

Driving the application logic

Now it’s time to take a look at the application logic file that drives this data validation process. Here is the relevant extract:

The application logic is specified in the Action element in the above snippet. This is embedded in a piece of interface logic which states that there is an Interface consisting of a “Button” labeled with the word “Submit”. The “OnClick” event on this button Triggers an Action on the part of the application. This Action displays in the Window named “customer”, and saves as a File in a specified location, the result of performing two nested transforms. The main transform consists of running an XSLT stylesheet against the context.xml file (some of whose content we have seen above). The stylesheet used to drive this transform is itself generated by an Action, namely to run the validate.xsl stylesheet against the datatype.xml file.

Notice that through this technique it is possible to dynamically generate stylesheets on the fly, to carry out complex sequences of transformations, to send the results to windows and to files, and to do all this in response to user actions on interface objects that were themselves generated by previous such transforms and events. Altogether a powerful set of capabilities driven by combinations of quite simple underlying data structures!

Previous

Table of Contents

Conclusion

We have seen through a few small examples how XML and its related specifications (particularly XSLT and XPath, can be used to drive a fully-functional application. The number of different data structures is quite small, and each one is quite simple.

When object-oriented programming came into being, it took some time before programmers and application designers had fully mastered the techniques and come to grips with the implications of the changing paradigm. The same will be true for XML-driven application design and development. But there can be no doubt that we are on the brink of an exciting period when new ideas will be put to the test and out of them will emerge powerful, robust, standards-driven application development paradigms. I hope the work shown here provides a useful contribution to that process.

Previous

Table of Contents

Acknowledgements

Previous

Table of Contents