|
An XML/EDI transport messaging prototype
|
 |
 |  | Find |
|
Abstract
|
The XML/EDI application described in this paper was developed as part
of an EU XML/EDI pilot project. This aimed to determine how the XML family
of standards can be used to develop the next generation of EDI applications
in two sectors - transport, described here, and healthcare. The application
shows how XSLT stylesheets can be used to drive a forms interface which is
device-independent, and which has multiple-language capabilities. It also
highlights areas where the XML family of standards was insufficiently developed
to cope with the requirements of a forms-based messaging system.
The core of the application comprises two modules which use XSLT stylesheets
to generate the interface resulting messages. The 'Generate Form' module outputs
a form in the mark-up appropriate for the user's device (e.g. HTML or WML),
and in the language selected by the user. It takes as input a form specification,
and resource files containing form labels and context references for data
items. The 'Validate' module validates user-entered values against a constraints
file, returns error messages in the user's language, and populates an XML
message from the data entered into the form by the user. Both modules use
generic and extensible data structures developed during the course of the
project, and are entirely independent of the application domain (in this case,
transport). They also make use of XSLT stylesheets which generate secondary
XSLT stylesheets, reducing maintenance and facilitating re-use by separating
domain-specific data from application code.
Two additional modules, driven by a browser ActiveX, are used to provide
elements which XML-based standards were unable to deliver. These modules are
'Process Control', which generates the interface used to drive processing
actions, and 'User Input' which saves values entered in then HTML form by
the user to file.
A key feature of the application is its ability to produce output in
the format appropriate to the user at the point in time at which it is needed.
The demonstration will show a message being generated for a WAP-enabled handheld
device, with a capability for the user to input a response to the message.
The project consortium made a number of recommendations to the European
Commission and to W3C on where XML standards should be further developed to
fill gaps in the current and projected standards coverage.
|
Contents
|
Overview
The EU XML/EDI pilot project within which this application was developed
was initiated and part-funded by the EU with the aim of determining to what
extent a web and standards-based systems could replace the use of EDIFACT-based
systems in selected domains, including transport. The move away from EDIFACT
was seen as desirable particularly for small and medium organisations for
whom the large investment in EDI systems was a bar to participation.
This paper deals with the development of an XSLT-based forms and messaging
application, describing the architecture used, and some of the benefits realised
by doing so.
Further information about the project, including the project deliverables
and details of the consortium members, can be found at http://www.tieke.fi/isis-xmledi/.
Previous
Table of Contents
Application scenario
The application was developed to meet the following scenario within
the transport industry:
- a customer has goods which have to be moved from one location to another
- having already selected a transporter company, they need to send them a message confirming the booking, and giving details of the goods to be moved and the locations
- they record the booking confirmation in a forms interface in a web-based browser
- the form validates the data, then saves the data as an XML file
- the data is sent as XML to the transporter, who may have an HTML or WAP browser
- the XML is used to create a booking reply form on the transporter's device, allowing them to see the details of the booking and accept or reject the booking.
Application summary
The key features of the application are as follows:
- forms are generated when required using XSLT stylesheets
- XSLT stylesheets are used in some cases to produce XSLT stylesheets, minimising the number of stylesheets required, and aiding maintainability
- the content and structure of the form is driven by a form specification which acts as a logical form
- source data for forms (e.g. labels, IDs, option lists) is held in a series of generically-structured XML files
- source data for processes (e.g. XPath expressions, validation tests) are also held in XML files, and are used as components in stylesheet assembly when needed
- the same form can be produced in any language and for a variety of devices (e.g. HTML, WAP)
- XSLT process control is driven by a browser ActiveX (RivComet), using processing commands in XML using an action control DTD.
The application modules described below are used at each stage of the
process with appropriate parameters to create the appropriate interface, and
to update the message file.
Process Control module
When the application is loaded into the browser, the initial HTML page
loads RivComet, which in turn drives a series of XSLT stylesheets which create
a toolbar comprising:
- a drop-down list of carriers, based on an XML carrier list file
- a drop-down list of languages, based on an XML language reference file
- a drop-down list of devices, based on an XML device reference file
- a series of buttons (e.g. Create form) allowing the user to control the application
Generate Form module
Each time a form is created, whether as a result of a user requesting
a new form, an existing saved data set being edited, or a read-only form generated
from message content, the same stylesheet processes are run, as follows:
- A generic XSLT stylesheet applied to the logical form specification for the form being built produces a second stylesheet. This retains the structure of the logical form, but also includes the XSLT expressions needed to populate it with the appropriate data.
- This stylesheet is applied to the XML message file (which may already
have content), and taking as parameters language and carrier user choices
in the settings file, populates the logical form with
- the form labels in the selected language
- the XPath expressions which link each data item in the form with its location in the XML message,
- existing data from the message file, if any.
- Finally, a third stylesheet is applied to the populated logical form to produce the HTML form itself, which is sent to a popup browser window.
User Input module
As the user inputs data, the values input are saved to a generic XML
file, along with reference IDs which enable them, through a reference file
of contexts, to be identified with a particular location in the XML message
file. As this process of saving to XML was not covered by XML or related standards,
it is handled by the RivComet browser application. Thus at any stage of input,
an XML file exists of values entered.
Validate module
When data entry is complete, the user clicks on a button to 'submit'
the data. In fact, this fires the validation process, which if successful
will populate the XML message file with the data, or if values fail the validation
process, revise the form to show the values entered and error messages. The
process is as follows:
- A generic XSLT stylesheet is applied to a datatypes XML file to produce an XSLT stylesheet which includes a template for each datatype. Each template contains the validation tests which are to be applied to data conforming to the datatype concerned.
- A second generic XSLT stylesheet is applied to the context XML file to produce the XSLT stylesheet which will run the validation. The context file holds the datatype of each data item, so the resulting generated stylesheet links the context reference of individual data items to the XSLT template in the first generated stylesheet described above.
- The generated stylesheets are applied to the XML file containing the form values, and an errors file produced. This contains, for each data item failing a validation test, the context reference of the item and the reference of the test it failed.
- A generic XSLT stylesheet is applied to the XML file containing the form values, using the context references in this file to produce an XSLT stylesheet containing the full XPath expressions needed to populate the XML message file with the data from the form.
- This stylesheet is applied to the XML message file, which may already be partially completed, to add the values entered by the user.
- If errors have been found by validation, the 'Generate Form' module is fired to regenerate the form, using the errors file to include error messages, drawn from the datatypes file.
- If no errors are file, a confirmation message is sent to the user.
Usage scenario
A typical usage scenario might be as follows:
- Message sender opens application in browser, selects carrier, 'English' language and 'browser' as device
- Form is generated in HTML with selected carrier, and with labels in English
- Sender enters data in form, clicks 'Submit'
- Data fails validation, form is regenerated including data entered and error messages
- Sender corrects errors, clicks 'Submit'
- Confirmation message sent to user, XML message file saved
- Message handling agent opens application with 'Finnish' selected as language and 'phone' as device
- Form is generated in WML, with data previously entered by sending user, and labels in Finnish
- WML file is picked up by recipient using WAP phone
- Recipient replies to message using WAP phone.
Conclusions
During the course of the development of the application, a number of
techniques and architectures were used which contributed to the objective
of constructing a standards-based, maintainable, generic and re-usable deliverable.
Key amongst these were:
- the use of stylesheets to generate secondary stylesheets, minimising the number of primary stylesheets required
- the development of the logical form, which is device-independent, but which holds all the information required to drive the construction of a form in the user's device
- the use of a series of dedicated XML files, all conforming to the same generic structure, to hold discrete parts of the data required to support the form processing
- the use of an 'action control' language to specify processing control within modules, interpreted in this case by RivComet, but capable of application in other XML-aware processors.
Acknowledgements
Thanks are due to the members of the ISIS European XML/EDI pilot project
for their contributions to the development of this application.