Write Once Display Anywhere
Analysis and Comment on the XML Document Navigation Language

Much of the hype surrounding XML has been the promise that it will allow the development of device independent Content which can be formatted by the web server at runtime using an XSLT Stylesheet which will deliver the Content to the target browser device in an appropriate format. It became obvious fairly quickly that for vastly different form factors of device this alone would not be enough. NEC Corporation of Japan have submitted a proposal to the W3C suggesting that an enhancement called XDNL (or XML Document Navigation Language) is the answer. This paper seeks to demonstrate that although XDNL is a step in the right direction, it in itself is still insufficient for real working systems.

"Write Once Display Anywhere" is becoming the Holy Grail of eCommerce Web Developers. As the wireless internet begins to takeoff, the programmers in the trenches at eCommerce, B2C and B2B websites across the globe, are coming under increasing pressure to produce more and more versions of their website, in more and more formats. There is HDML and WML just for mobile phones, there might be output for Pagers and there is almost definitely PDA devices running a collection of different OSes and Browsers such as AvantGo.

One portal website manager recently reported that their site is now produced in 20 formats. That is a lot of extra coding. It would be ideal if some automated mechanism could be found to alleviate that drain on manpower. If only there was a way to Write Once and Display Anywhere. XML and XSLT Stylesheets have offered that promise.

Stylesheets alone were not the answer

The main problem with Stylesheets is that they have no regard for Navigation or Interaction. Stylesheets are fine for finessing a "look" but they have little impact on "feel". If you are delivering output to a family of devices with much the same characteristics then the navigation may be unaffected from one style to another. However, with fundamentally differing form factors such as a WAP Phone and a PC Web Browser, navigation becomes an issue.

The key is to recognize the basic fundamental difference between a PC Screen and a WAP Phone. A PC Screen is a largely a-modal interface which offers the facility to present a large number of navigation choices to the User. These choices can be randomly accessed in an a-modal fashion. With a WAP Phone the opposite is true. A WAP Phone is a very very modal device. The conversation with a WAP Phone is more like a telephone conversation with a hotel concierge. It is one question at a time, one answer at a time until gradually enough information is known in order to do something useful, type of conversation.

Stylesheets alone are not going to solve such a complex problem.

XDNL - The Navigation Sheets Solution

The XDNL proposal suggests that using XML to encode the basic Content and an XDNL document to describe the navigation for different form factor devices, this problem can be solved. The principle is simple: write a navigation sheet for each family of target devices and use it at runtime on the server to only serve the appropriate section of the original Content document.

Diagram1.Two Content Pages in XML with 6 Data Items per page

XDNL suggests that Content pages like those above can be encoded to tell us the structure of the content. In this example, there is a very simple structure. Just two pages each with 6 paragraphs or items of data.

An XDNL Document is prepared separately (somewhat like a stylesheet) which describes how the navigation should work within a single document.

For delivery to a large PC Display this may be empty or extremely simple. The data shown would give us a navigation which looks like this.

When delivering to a small form factor device such as a WAP Phone, the XDNL Document comes into play and describes how the navigation would work. In this case, a scheme to display a single paragraph per card in a WML Deck has been chosen.

In this example, the XSLT stylesheet would be formatting the output as WML suitable for the phone. The XDNL document would be telling the Server which original Content to push through the XSLT processor. In this example, we are showing the whole of the first page being delivered in a single deck. We could have chosen a different navigation scheme which would have delivered only the first 3 cards in a deck and the second three in a subsequent deck.

What is good about XDNL?

This scheme is interesting because it is un-intrusive on the original data. It allows the original data to sit in an XML Content document and never be disturbed. It is, however, dependent on the structure tags used in that original XML document but that is understandable.

The XDNL is also independent of the XSLT Stylesheet. In principle then XDNL delivers Navigation or "feel" whilst XSLT delivers Appearance and Device Formatting or "look". So together they deliver "Look and Feel"? Unfortunately, not completely!

What is bad about XDNL?

The real problem with XDNL as it stands at the moment is that it really only addresses the navigation of information. There is no behavior permitted. XDNL as it stands will not support any web interaction which requires Form submissions, or URL rewriting used for behavior or as input to business logic. In other words, it is for informational sites only - simple hypertext.

UML Statecharts - an established notation for behavior in event driven systems

There is, however, an established notation which allows us to describe navigation with behavior in Event Driven systems. The World Wide Web is an Event Driven System. The Events are HTTP Requests. They might be called "request" but they are Events. The server processes the Event and sends a response, traditionally an HTML document. There is much more detail on how to model a website with Statecharts given in the White Paper : Web MVC Part 1.

We can look at the Statechart Models for our earlier designs. First, the HTML target style.

Here we have a single state to model the first page, WebPageA; a single event to model the Navigation from page A to B, Event NextPage; and a single state to model the second page, WebPageB. The initial dot is merely the Start State in the Statechart Notation and the circled dot is the End State. They are included for completeness.

Now let us consider the Statechart for delivery to the WML target style.

In this example, we are modeling the first Deck as a single State, Deck A. Deck A has 6 substates for each of the Cards in the navigation sequence. The Start State tells us that when we first enter the State, DeckA, we will automatically enter the substate Card1. The system could be said to be in the state DeckA.Card1. The second Deck is modeled in a similar fashion. Note that the Event from Card6 takes us to State, DeckB. We rely on the Start State inside DeckB to take us to the substate, CardB1. When we enter DeckB, the system will automatically be set to State, DeckB.CardB1.

The examples given here are somewhat simple. Still we have simple navigation with no behavior. Let us now consider behavior.

Imagine for a second that each of these segments of data in our original XML document had within it a Form or some Input requirement. Imagine that WebPageA now has to become a single Form Submission and in turn DeckA is also a Form Submission. We may now wish to validate our parameters with an appropriate scripting language.

So on our HTML version, we require to drop into the server stream output for WebPageA, a Javascript sequence which will validate our 6 parameters.

For our WML version, we require to drop 6 little pieces of WMLScript into the Cards on the Deck which will validate each parameter as it is entered. This is desirable from a Usability perspective. So how do we model that?

What has happened here is that we have added some Event processing to our NextPage Event. The Event passes the parameters to the server and the Server evaluates the Conditions to see that the input is good or not. If not then it returns to the previous State [ note: this is actually simplistic, it would really have to return to a substate which displayed an error message ]

So we have added, "if ... then ..." logic to our Navigation. XDNL as it stands cannot do this.

When we examine the model for the WML version, we see that the model quickly becomes cluttered with all the Event Condition evaluation which is happening. For clarity most of the condition evaluation has been left off the diagram. Note, however, that each substate has two Event arrows one for the "if..." case and the other for the "then..." case.

Condition Evaluation provides us the basic mechanism to allow branching in the Navigation Scheme based on User input.

Actions

There is a second type of behavior which we need in a navigation mechanism, other than the Condition Evaluation we have just shown. This second type of behavior is known as an Action. An Action is something which must happen after an Event transition takes place but just before the new State is entered.

One key use for Actions is the scoping of Database Transactions. Typically, the Begin Transaction, the Commit and the Rollback of a transaction will happen as Actions. The ability to manage transactions is fundamental to eCommerce Websites and Application Service Providers and Extranet Sites and the list is endless.

Here is a basic example of how we can model the Transaction Boundaries onto a Statechart. Note the Transaction Boundary is not part of the currently adopted UML Statechart notation but is shown as an aid to understanding.

It is important that a Transaction only have a single starting point. A discussion of why this is so is out of the scope of this paper. The Starting point is given when the First Page is entered. An Action is set on the initialization of the FirstPage State, which will cause a Database Transaction to begin. The appropriate server-side script would be run to make this happen.

The other important Actions are the Commit and the Rollback. Commit or Rollback must happen when the navigation crosses outwith the Transaction Boundary. The Commit Action is set to happen when the Navigation moves to the Good Exit State. In other words, the Name, Address and Credit Card Number have all validated correctly. The Rollback Action will happen if any of the earlier parameters were not valid. [ Note: again this is a simplified example ]

Now consider how the Transaction Boundary will look on the WML Version

Navigation Conclusions

So, we have shown that for the complex navigation required in a transactional eCommerce Web Site, both Condition Evaluation and Event Transition Actions are required. Both of these require code. Some of that code needs to run as client side script and some of it as server-side script or other compiled language.

We have also demonstrated that there is a sufficient and industry standard notation for modeling a World Wide Web application site with navigation, condition evaluation and actions. That notation is UML Statechart Notation originated by David Harel.

If we are to move toward the goal of "Write Once Display Anywhere" then we must look to encapsulate a Statechart description of the intended delivery mechanism e.g. HTML, WML, HDML, as a composing document for XML Servers. We must also look to encapsulate in an accessible fashion, the ability for the XML Server to run the appropriate logic on the server when it is required.

It will therefore be necessary to develop not only XML Content suitably encoded, together with XSLT Stylesheets, but to add a Navigation document which describes the flow of Events and allows for the behavioral aspect of Condition Evaluation and Actions to be run in a suitable Script or server-side language or class.

The current XDNL proposal is a place to start but it will prove unworkable for real websites.

It's time to start work on a Super XDNL which encapsulates a Statechart as a DTD and allows links to real code.

Delivering this is no trivial task and even when it's done there is still no guarantee that you can "Write Once Display Anywhere". In the meantime, we must look to do the hard grafting of developing a separate version of each site for each family of devices.

References:

XML Document Navigation Language, NEC Corporation, March 2000