Aeronautical Information Services (AIS) and XForms

One area where we give ourselves in the hand of technology is air traffic. As soon as we enter an airplane we have to trust a complex machinery and hope that machines, pilots and ground personal are doing their job right and bring us safely back to the ground. But flying does not only involve airplanes and well-trained pilots but mountains of data about airports, airspaces, run ways, weather conditions etc. etc.

A important acronym in this domain is ATM which stands for ‘Air Traffic Management’. Two of the most important organizations in air traffic are the Federal Aviation Association (FAA) and Eurocontrol. Together both organizations developed a conceptual model of the whole aeronautical domain and also offer an implementation of that model in XML Schema. This is the technological foundation for Aeronautical Information Services (AIS) that allow the digital exchange of data between all relevant parties.

However it takes more than a schema to build an application. The schema describes all the entities, objects and their relationships and it’s up to the software vendors to build complete solutions from that. All the data that are needed to ensure a high level of safety in the operation of air traffic must be entered by humans and those need good user interfaces to do their job. The gathered information is then used on-flight to give pilots up-to-date information about outages, special conditions at certain airports, restricted airspaces and so forth.

This is where XForms comes into play. The aforementioned schema consists of about 4 megabytes of schema definitions and about 150 ‘features’ and same amount of ‘objects’ as they are called in this model. These ‘features’ and ‘objects’ can then be combined with each other, nested within each other and linked to other ‘features’ and ‘objects’. All this happens at runtime when ground operators build complex messages from the available set of entities.

Though clean from a conceptual view this highly dynamic model puts heavy burdens on the engineers and eliminates any possibility to build static user interfaces to support all types of messages. Fortunately the authors of XForms decided to build it upon XML and as such it is ideally suited to be generated from a formal description such as a XML Schema.

The application described here was build by a leading vendor of Air Traffic Control (ATC) solutions.Their engineers have choosen a SOA approach to provide maximum flexibility and connectivity with other applications. In the backend a large Oracle database is used to store all the collected data. The whole user interface for collecting and maintaining the data is generated from the XML Schema resulting in about 300 separate XForms documents using several dozens of custom datatypes. Each form comes with its own template instance which represents one entity from the schema. Those template instances are then aggregated at runtime to build a certain message to be stored in the database.

The necessary aggregation of instances and associated user interfaces was a problem that couldn’t be solved elegantly with XForms 1.1. The key to success was a tiny extension to XForms allowing forms to be embedded in already loaded ones. With an additional value ’embed’ for the attribute ‘show’ of the XForms load action and an attribute ‘targetid’ this extension is only a very small addition to the language set of XForms. Here’s an example:

<xf:load show="embed' targetid="foo">
    <xf:resource value="'myResource'"/>
 </xf:load>

This extension has already been proposed for XForms 2.0 which is currently under development.

Additional challenges had to be met: we needed a way to exchange instance data of a subform with their respective ‘master’ and to allow to ‘mount’ some piece of data into the master instance to build a complete messages. We developed several solutions to this that do not break the encapsulation of the target model but discussion of the details is left to another blog post. Further we had to find a user interface presentation that allows an operator to keep the overview over a complex document. To solve this we implemented a tabbed control behaving like a XForms repeat – for each loaded subform a tab is dynamically added and shows the respective subform within it. An additional breadcrumb navigation helps to keep track of the hierarchy in the document. Last but not least the instance data of a stored message are not allowed to contain empty nodes. Thus when loading a stored message for editing the data had to be merged with their template instances. This was solved with a XSLT transform to be executed whenever a message was read from the web-service layer of the database.

After heavy and serious testing the customer was able to deliver the first implementation of the standard worldwide which is now in production use in several countries. Soon after first release the generative approach proved itself valuable as the application needed to be migrated to a new XML Schema version. With a single excecution of the XForms generator the new forms were available and could be used right away.

We think this project is an impressive example of the power of XForms. To summarize the facts:

• 300 generated XForms documents
• about 50 custom datatypes
• a highly dynamic user interface embedded inside of a portal
• about 4 megabyte of raw XML Schema data using about a dozen of different namespaces
• massive use of optional elements
• all forms connected to SOAP web-services
• running in a standard web browser without any plugins
• not a single line of script code was necessary to implement the forms