ebXML   Table of contents   Indexes   B2B integration
 

An XML/EDI transport messaging prototype

Scott, Antony
 
 Antony  Scott
 Senior Analyst
  RivCom 
 Swindon 
 United Kingdom 
 Wiltshire 
RivCom,  Lotmead Business Village
Wanborough
Swindon  Wiltshire  SN4 0UY United Kingdom
Phone: +44 (0) 1934 835851 Fax: +44 (0) 1934 838676 email: antony.scott@rivcom.com web site: www.rivcom.com
 Biography
 Antony Scott - has been developing XML applications at RivCom for the past three years, and has ten years experience in writing and publishing structured documentation. During 1999, he was a co-developer on the European XML/EDI Pilot Project to develop good practice guidelines and prototype applications to show how the XML family of standards can be used to develop the next generation of EDI applications. He has spoken at the following industry conferences: Document 98 (Birmingham, UK); SGML UK October 1999; European XML/EDI Pilot Project Dissemination Event December 1999. Antony Scott has also conducted extensive application-specific training for users and managers.
 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.
 

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/ .
 

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
    • As the user makes their choices in the three drop-down lists, the values selected are saved by the RivComet application in a settings file. The user then clicks Create form to generate the form.
     

    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.
    ebXML   Table of contents   Indexes   B2B integration