Table of Contents

Introduction This Project Requirements and Solutions Three Core XML Formats Transformations and the "Logical" Format The Identity Crisis Action Language Needed? Conclusions

Building a Client-Side XML Application

By Tony Stewart
Senior Consultant, Flash Creative Management, Inc.

Introduction

This presentation describes a project I was involved in last year, when I served as Director of Consulting at RivCom, an XML consulting firm based in the UK. The project, entitled "XML/EDI in the Transport Industry," was part of a larger European XML/EDI Pilot Project that ran throughout 1999.

In this talk I focus on a few key concepts that I believe have general relevance to all XML application developers. The project covered much more ground than I will go into here. If you want to know more about the project:

• For technical details, see "Building a Client-Server XML Application - Background Notes" on Flash Creative Management's website (www.flashcreative.com).
• For an overview of RivCom's involvement, see their website (www.rivcom.com)
• For the deliverables of the project, see its official website (www.tieke.fi/isis-xmledi)

The Vision of Client-Side XML Processing

The excitement underlying electronic commerce is about bringing people and markets together electronically. Such an interaction is based on a high degree of interconnectivity and interoperability.

XML is emerging as a major technology for interoperable and transparent global communications over the Internet and the Web. XML enables the exchange of "smart data", or dynamic information, which can be readily analyzed, sorted, styled, customized and personalized. XML is expected to extend the capability of the Web from a static world library to the world's commercial and financial hub. This should lead to a profusion of diverse, interoperable and innovative electronic commerce services in a global and unitary market space.

This vision of an interconnected B2B world rides on a series of assumptions and prerequisites:

• Organizations that participate in a given industry or activity join together to form a "business community".  For example, the major automobile manufacturers and the companies that supply them have already formed a "car-making" community;
• Within this community, the participants agree on the types of information that need to flow between them. For example, the car-making community would be interested, at a minimum, in information about automobile parts.
• Participants transform this key information into standard types of XML messages, and use XML Schemas (or DTDs) to publish the structure of those messages so all members of the community can read and write the messages using the same XML "language".
• Larger enterprises in the community implement sophisticated systems that generate or receive the messages and route them in and out of the relevant business applications.
• Smaller players use lightweight, off-the-shelf tools to receive and display the messages, which can then be acted on or transferred into their internal applications by a more manual operation.

The Challenge

The current explosion of XML-based B2B activity focuses on creating these communities, their shared schemas, and the tools (such as BizTalk) that they will use to generate and route the information. This approach is considerably more lightweight and flexible than the heavy EDI systems of the previous generation, and much smaller companies can now participate.

But there is still a gap for the really small players, companies with 10 or 50 employees and no in-house IT department. They don't have custom systems that can receive e-commerce messages and act on them automatically, and they don't have the budget or the bandwidth to implement such systems. Instead, they want to be able to display the messages in a browser or similar ubiquitous device, respond to them manually, and perhaps paste the contents into another document or application.

XML is the perfect medium for this kind of semi-manual processing, because it carries the content of the message in a medium-independent format, and it provides mechanisms to add formatting and behavior as appropriate to the current environment and display device. The challenge is to deliver these capabilities in an inexpensive, lightweight toolset that small players can really use.

This Project

"XML/EDI in the Transport Industry" was a proof of concept / demonstrator project whose purpose was to determine whether it was possible to build a useful, client-side XML application using only XML standards and freely available tools, rather than proprietary (non-standardized) script or code. To the extent that this turned out not to be possible, the project identified weaknesses and gaps in the standards that would need to be filled in order to accomplish this in the future.

Project Goals

The goal of the project was to create a prototype in which a thin client would receive an XML e-commerce message, and using XML documents such as style sheets and simple metadata, it would call upon standardized components to produce reliable, repeatable behavior:

• Translate an incoming, standardized XML message into the user's human language (the project took place in Europe, so languages were an important issue)
• Generate appropriate labels for the display fields
• Format the information and display it in a browser using a combination of display-only and editable input fields 
• Upload the user's changes as a new XML document conforming to the standardized schema
• Transform this updated document into WML and display it on a handheld device

In order to achieve this goal, the project restricted itself to the following tools:

• IE 4 or 5 (the most widely-used browser, effectively free for Windows users)
• XT (a free transformation processor that implements the XSLT standard)
• OmniMark (a freely-available server side script processor which was used to set up a simple CGI script)
• RivComet (a proprietary client-side XML processing engine which was used to fill the same role for which, say, a Microsoft-oriented developer would have used Jscript inside IE)
• The Nokia WAP toolkit (for converting XML messages into WML and displaying them on a mobile phone)

Overview and Context

While the points I want to make in this presentation are not limited to this specific application, it does help to follow them if you understand the context for which the application was created. In this case, we automated a portion of the Scandinavian transportation industry.

1. A consignor books a transportation order via his Web browser.
2. The information is sent to the shipper in a standard XML/EDI format
3. The shipping company converts part of it to Wireless Markup Language (also an XML language).
4. The WML is transmitted to a truck driver and displayed on his mobile phone or pager.

Although the project covered a lot of ground, most of this talk focuses on what was required in order to display the message in the shipper's browser, and then capture the shipper's updated information and convert it into XML for transmission to the trucker. Here is what the user sees when running the application.

1: Select the Language

When the browser form first appears, it contains a Language drop-down in which the user (who is pretending to be a shipment consignor) gets to specify whether he wants to see the form in English or Finnish. (This was for demonstration purposes. In a live application, the language choice would be read from a configuration or security file.)

Figure 1: Language selection drop-down.

Assuming the user selects "English", a form appears in which the user can enter details of the transportation order. Some of the information from the incoming message is displayed in read-only text at the top, while other fields are formatted for user entry, either as text or radio buttons:

Figure 2:  Transportation booking form with English-language labels (partial view).

2: Fill in the Order

The user fills in the required information and presses Submit.

Figure 3:  Booking form with contact details.

3: Send the Order to the Trucker's Mobile Phone

On the server, a script receives the HTML, converts it into a standardized XML format for exchanging transportation booking requests, and forwards it to another server where it is converted into WML (Wireless Markup Language) and broadcast to the trucker's mobile phone. It is displayed on the phone along with menu options that tell the trucker how to reply.

Figure 4:  Booking order displayed on mobile phone.

Requirements and Solutions

In this talk I'm going to focus on a few of the high-level requirements of the project, and on the core concepts that made their solution possible.

In the view of the project team, the critical requirements were:

• Accommodate multiple display devices
• Display descriptive text in the user's own language
• Use standard, inexpensive off-the-shelf tools
• Require as little programming as possible in order to implement the solution

The solution we developed had three main components:

• Build a library of reusable XML/XSL components
• Transform the information repeatedly to optimize the use of these components
• Use XPath to identify and map information fragments.

Transformations Are the Key

In XML, a "transformation" is the process of automatically converting an XML message to another format (either to XML conforming to a different schema, or to something other than XML such as HTML). The XML family of standards contains one, XSLT, whose purpose is to standardize the way these transformations are specified. XSLT transformations are performed by a transformation processor, which takes as its input one or more XML messages, and one or more XSLT stylesheets (which themselves are XML documents conforming to the XSLT standard). The processor applies the rules contained in the stylesheets to the information in the incoming XML message(s), in order to create one or more output files.

Transformations are the building blocks of an XML application, because they allow us to work with the information in a format that is optimized for the processing that we are performing. For example, when a business community agrees on a format for exchanging XML e-commerce messages between its members, they are creating an XML language that is optimized for the task of exchanging the information they care about. But when you write a system to manipulate or display the contents of those XML messages, you may well discover that the interchange format, which was optimal for communication between companies, is not well suited for the kind of processing you want to perform. Rather than writing convoluted code, your best bet is to transform the information into a format that is appropriate for the desired processing, then write appropriately simple processing routines to run against this optimized format.

The general procedure is:

• Start with an "external" message format that is optimized for communication between companies, and for which the schema has been locked down and published (either within the community or in a broader forum)
• Transform this into as many internal formats as necessary. These should be designed to support internal routines that you can re-use again and again on different projects that come along.
• When you have finished your internal processing, transform the information back into the "external" format for transmission to other members of your business community.

This same procedure can also be adopted within an organization, when you are routing XML-encoded information between components of the system: you can work with the information any way you want locally, provided that you send it to the next system component in a standardized format

Three Core XML Formats

In this presentation I focus on the processing that takes place inside the user's browser. Although in this project the processing was deliberately implemented inside the client device in order to push the envelope, the same concepts would apply in a server-side application.

The core of the application is a series of transformations between three main XML formats, each of which conforms to a different schema.

The "External" Format

The information arrives in an "external" format that is standardized for use in the European transportation industry. This industry is currently using a complex UN/EDIFACT format that was standardized some years ago. For this project, we developed an XML schema containing the same information as the UN/EDIFACT format. (This simulates what happens when a business community develops its own e-commerce ...

Due to an error, this article has been truncated.  We apologize for this.