This paper describes how the XML XForms standard is being used within the United Kingdom Government's initiative to offer all services online and improve interaction with Government. Using XForms is a key component of this initiative, offering a general solution where forms need to be standards-based and portable, but at the same time customised for local variants of parallel services.

UK Government services are delivered by tiered Government organisations. National organisations are responsible for horizontal functions such as defence at the national or country level. Local Authorities are responsible at two levels, county, and at the most local level, city, metropolitan borough, and district councils. The different levels of local authority offer a similar range of services, such as Health and Education, with their own staff and budgets to develop policies and serve individuals in the local community.

Offering e-services across Government presents the challenge of

As well as a challenge, this offers the opportunity for making contact more readily available, for intelligent electronic forms, and for significantly reducing the cost per transaction.

The first project chosen to test the e-Government architecture and the XForms concept for local authorities was Council Tax. This is a local tax on all households to pay for local services and with a variety of reductions and discounts for students, people living on their own, and those with special needs. A high proportion of individuals have this interaction with the Local Authority, giving good prominence and service improvement.

To achieve maximum uptake of the development within the e-Government XML framework, the technology requirements were for

This led to the concept of using a standard XML message embedded in forms which can be rendered through a variety of channels and customised with captions and a choice of languages relevant to the local community. The XForms recommendation provides features which allow these requirements to be met as described below

The following diagram illustrates the software architecture which has been developed to build and render a specific form:

On the left are the documents required to define the logical content of the form starting with a generic XForm definition as described above. Associated with this are the additional documents defining the default content of captions and help text in multiple languages and allowing the Local Authority customisation of this content.

These documents are pre-processed to produce the specific instance of the XForm to be used throughout the transaction. This form can optionally be pre-populated by sending the XML instance template to the Local Authority via the Government Gateway.

The XForms processor then manages the communication with the client to produce the completed (and validated) XML. There will be a generic processor for each required client, with two parts. The XSLT processor produces the form content in a displayable format. The server then adds Local Authority's own styling, for example to incorporate the service in an existing Web site, and manages the communication with the client and validation of the inputs. If there is a need for business rule processing, this will be carried out here.

An entire complex form can be specified as a single XForms document, which contains information regarding the structure and type of the data and a generic layout. Help and caption definitions allow the same form to be customised for each Local Authority. Default captions and help are used if no local entries exist. This method can also be used to provide text in different languages as required, for particular communities and the statutory bilingual requirement in Wales.

The XForm itself is made up of the instance, model, bindings and the ui-section. Every element contained within the form and its context with regard to other elements is specified in this file. Control that appears on the display is outlined within this file, also with regard to its context within the form. However the actual contents of the captions and help are not defined here, but in external caption and help files in default and optional locally customised versions. The order that the elements appear on the form and the name of each element are defined within this section.

Structure:

		<? xml version="1.0"?>
		<al:form>
		 <xform:xform>
		 <!-- unordered (xform:instance, xform:bindings, xform:model)
		  -->
		 </xform:xform>
		<!-- al:toggle element(s) -->
		</al:form>
        

Within the <form> element are two different types of elements, <xform> and <toggle>. <xform> contains all information about the instance and any bindings between the data and its schema (the <model> element) and its data (the <bindings> element). The <toggle> element can occur more than once and defines the representation of the form one page at a time.

The <xform> tag consists of <instance>, <model>, and <bindings> elements.

The <instance> tag contains the actual elements for storing the data, in their own structure in the form itself.

The <model> tag points to the schema used to validate the instance described by the <instance> tag above

Example:

<xform:bindings>
		 <xform:bind ref="/CouncilTax/PersonalDetails/Surname"
		  required="true" al:errormsg="Sorry..."/>
		</xform:bindings>

The <toggle> elements contain the details of how the actual form is laid out, one page at a time, and how different elements relate to each other on the 'page'

The Schema

The schema has its own target namespace which is unique to each XForm, and may be used to validate the instance after completion by the user before submission to the backend system.

Example:

<xform:instance 
  xmlns:xform="http://www.alphaxml.com/ns/xforms"
  xmlns="http://www.instances.com/HousingBenefit"
  targetNamespace="http://www.instances.com/HousingBenefit"
  xmlns:xsd="http://www.w3.org/XMLSchema"
  elementFormDefault="qualified">
  <CouncilTax>
  <!-- all sub elements are defined here -->
  </CouncilTax>
</xform:instance>

This schema can be used to create the other necessary schema when adding an XForm, the 'empty schema'. The 'empty schema' is explained below.

Default Files

There are two default configuration files, one to provide the default captions and the other default help text. Both file types have the same basic structure and use the same namespaces.

Examples:

The captions file:

<?xml version="1.0"?> 
<al:LAcaptions
  xmlns:al="http://www.alphaxml.com/ns/xforms/extensions"
  xmlns:xform="http://www.alphaxml.com/ns/xforms"> 
 <xform:caption id="C-HB-00010-A">About you and your
  partner:</xform:caption> 
 <xform:caption
  id="C-HB-00020-A">You</xform:caption> 
 ... 
</al:LAcaptions> 
The help file: 
<?xml version="1.0"?> 
<al:Lahelp
  xmlns:al="http://www.alphaxml.com/ns/xforms/extensions"
  xmlns:xform="http://www.alphaxml.com/ns/xforms"> 
 <xform:help id="H-HB-00010-A">Please enter your surname in
  the space provided</xform:help> 
 ... 
</al:LAhelp> 

Customisation Files

Optional customisation files equivalent to the defaults may be used within the alphaXML XForms processor to change the captions so that people from one area see different captions dependent on their Local Authority, or to display the forms in an entirely different language.

Form Pre-population

Pre-population may be used where data already exists, for example to fill in the name and address of the applicant given their account number. This is a major advantage of e-forms. The message instance is extracted from the form sent to the relevant host via the Gateway as an XML message for data retrieval.

XML schema is the UK e-Government Interoperability Framework's standard for defining XML vocabularies, and they have developed their own schema guidelines and development frameworks which are the subject of other presentations at this conference. Architectural schemas are available to foster interoperability between different e-services, and consultation is carried out and schemas published through the Web site www.govtalk.gov.uk.

For the Council Tax service schemas, to cater for all Local Authorities, a workshop was held involving 16 Local Authorities to define processes and schema requirements. This was followed up in more detail with 2 lead Local Authorities, one urban and one rural, followed by wider consultation through a govtalk forum (www.govtalk.gov.uk).

Once schemas have been defined for a particular application, re-usable components are fed back into the pool of schema components for future developments. A related project originally linked with Council Tax is Housing Benefit, a payment to entitled members of the community which covers Council Tax payments.

To deliver XForms to particular platform needs a processor to deliver the assembled form to that device. The UK Government's initial target platform is a Web browser, for which a processor has been developed.

Most of the interaction with the user is carried out by an e-forms. server, which forwards the completed form set as an XML message to the Government Gateway. The Gateway looks at information in the message envelope to authenticate the sender, check that s/he is authorised to perform the transaction requested, and route the message to one or more destinations. The Gateway adds a standard XML envelope to the message payload, and routes transactions to and from the serving department. Here, XML provides a standard interface to the variety of Local Authority Council Tax systems.

It is anticipated that this pilot use of XForms for Local Authorities will be widely used elsewhere for services which are offered by similar organisations who are able to cooperate and share development costs. In this application, the ability to customise text associated with form fields is initially more important than the ability to render to different platforms, which is perhaps a more commonly exploited feature of such technologies. The Government Gateway is another important infrastrusture component which offers shared services such as registration and security to all Government organisations.