(Re)presentation in XForms

Steven Pemberton, CWI, Amsterdam

Alain Coutures, AgenceXML, France


  1. Contents
  2. Abstract
  3. XForms
  4. Principles
  5. The Model
  6. Properties
  7. Properties
  8. Properties
  9. Properties
  10. Properties
  11. Properties
  12. Content
  13. Declarative Controls
  14. The effect of properties on presentation of controls
  15. Relevance
  16. Presence = relevance
  17. Types
  18. Required
  19. Read-only
  20. Validity
  21. Implementation approaches
  22. XSLTForms
  23. Design of transformations
  24. Example
  25. Transformation
  26. Transformation
  27. Integration in HTML+CSS
  28. Relevance and CSS
  29. Required and CSS
  30. Validity and CSS
  31. Validity and CSS
  32. Improvements
  33. Styling of labels
  34. Styling of required
  35. Styling of validity
  36. Cascading
  37. Background
  38. Alert
  39. Styling Flexibility
  40. Other label positions
  41. Skinning
  42. Skinning
  43. Example
  44. Future Transformation
  45. Example transformation
  46. Conclusion


XForms is an XML-based declarative programming language. XForms programs have two parts: the form or model, contains descriptions of the data used, and constraints and relationships between the values that are automatically checked and kept up to date by the system; and the content, which displays data to the user, and allows interaction with values.

Content is presented to the user with abstract controls, which bind to values in the model, reflecting properties of the values, and in general allowing interaction with the values in various ways. Controls are unusual in being declarative, describing what they do, but not how they should be represented, nor precisely how they should achieve what is required of them. The abstract controls are concretised by the implementation when the XForm application is presented to the user, taking into account modality, features of the client device, and instructions from style sheets.

This has a number of advantages: flexibility, since the same control can have different representations depending on need and modality, device independence, and accessibility.

This paper discusses how XForms content presentation works, and the requirements for controls, discusses how one implementation, XSLTForms, implements content presentation, and the use of CSS styling to meet the requirements of controls, and future improvements in both.


XForms is a declarative markup for defining applications.

It is a W3C standard, and in worldwide use, for instance by the Dutch Weather Service, KNMI, many Dutch and UK government websites, the BBC, the US Department of Motor Vehicles, the British National Health Service, and many others.

Largely thanks to its declarative nature, experience has shown that you can produce applications in much less time than with traditional procedural methods, typically a tenth of the time.


XForms programs are divided into two parts:

  1. the form or model, which contains the data, and describes the properties of the data, the types, constraints, and relationships with other values, and
  2. the content, which displays values from the model, and allows interaction with those values.

This can be compared with how HTML separates styling from content, or indeed how a recipe first lists its ingredients, before telling you what to do with them.

The Model

The model consists of any number of instances, collections of data that can either be loaded from external data:

<instance src="data.xml"/>
<instance src="https://example.org/data?q=2020"/>

or can contain inline data:

   <payment xmlns="">


Properties are assigned to data values using bind elements. Properties can be:


Properties are assigned to data values using bind elements. Properties can be:


Properties are assigned to data values using bind elements. Properties can be:


Properties are assigned to data values using bind elements. Properties can be:


Properties are assigned to data values using bind elements. Properties can be:


Properties are assigned to data values using bind elements. Properties can be:


Controls display, and allow interaction with, values. Examples are:

Declarative Controls

Controls bind to values in instances.

They are unusual in that they are not visually oriented, but specify their intent: what they do and not how. Visual requirements are left to styling.

Result: the controls are device- and modality-independent, and accessible, since an implementation has a lot of freedom in how they can be represented.

The controls are an abstract representation of what they have to achieve, so that the same control can have different representations according to requirements.

The effect of properties on presentation of controls

Thanks to this freedom, implementations can (and sometimes must) take the properties of the values into account in deciding how to do it.


The major effect is based on relevance, and demanded by the language: if a value is not relevant, then the control it is bound to is not displayed.

Most properties depend on a boolean expression, so the property can change at run time.

For instance, if the buyer is not paying by credit card, then the control for input of the credit-card number will not be displayed:

<select1 ref="paymenttype" ...</select1>
<input ref="creditcard" label="Credit card number"/>


Presence = relevance

Values that are not even present in the data, which can be seen as a sort of super-nonrelevance, is similar: controls that are bound to values that are not present are also not displayed.

This is in particular useful for data coming from external sources, where certain fields may be optional in the schema.

A value may later become available, for instance as a result of insertions, so that the control has nevertheless to be ready to accept a value.



An implementation can adapt controls to the type of data (this property is not dynamic).
A control bound to a date can pop up a date picker.
A control bound to a boolean, can be represented as a check box.

<input ref="name" label="string"/>
<input ref="size" label="integer"/>
<input ref="truth" label="boolean"/>
<input ref="today" label="date"/>



Other properties don't affect the form of the control, but other styling.

A control bound to a value that is required, can get a small red asterisk next to the label, or a red background, or both.

<bind ref="state" required="../country='usa'"/>
<select1 ref="country" label="Country">
<input ref="state" label="State"/>



A control for a value that is readonly should make it clear to the user that the value is not changeable.

<bind ref="name" readonly="../edit=false()"/>
<input ref="name" label="Name"/>
<input ref="edit" label="Change"/>



For both type validity and adherence to a constraint property, a control can indicate the validity, either positively or negatively.

All controls can have an associated alert message, displayed when the value is invalid:

<input ref="creditcard" label="Credit card number"
       alert="Not a valid credit card number"/>


Implementation approaches

XForms was deliberately designed to allow different implementation strategies. For instance:


One widely used implementation, XSLTForms, works by using XSLT to transform the XForm in the browser, client-side, into a combination of HTML and Javascript, so that all processing takes place on the client.

This has an additional advantage, over a pure server-side implementation, that 'Show Source' shows the XForms source, and not the transformation.

Design of transformations

Such an approach requires the design of equivalent constructs in HTML+Javascript to implement the XForm constructs.

Since XForms controls contain a lot of implicit functionality, even apparently simple cases can require quite complex transformations.


As an example, the transformation of

<input ref="creditcard" label="Credit card number"
       alert="Not a valid credit card number"/>

gives the following HTML (plus a number of event listeners to implement the semantics):


<span class="xforms-control xforms-input xforms-appearance xforms-optional
             xforms-enabled xforms-readwrite xforms-valid"
   <span class="focus"> </span>
   <label class="xforms-label" id="xsltforms-mainform-label-2_2_10_2_4_3_"
         >Credit card number</label>
   <span class="value">
      <input class="xforms-value"
             id="xsltforms-mainform-input-input-2_10_2_4_3_" type="text"
             style="text-align: left;"/>
   <span class="xforms-required-icon">*</span>
   <span class="xforms-alert">
      <span class="xforms-alert-icon"> </span>
      <span id="xsltforms-mainform-alert-4_2_10_2_4_3_"
           >Not a valid credit card number</span>


This exposes two essential aspects of the transformation:

In this case you can see that it is recorded as being:

These last four values are dynamic, depending on a boolean expression and the type, and can change during run-time, for instance xforms-valid can become xforms-invalid.

Integration in HTML+CSS

One advantage of using HTML as target code is that you have the power of Cascading Style Sheets (CSS) at your disposal to support presentation.

In particular the CSS can use the class values as shown in the examples above to affect the presentation.

Relevance and CSS

The most obvious case is when a value becomes non-relevant, and therefore the control becomes disabled.

CSS can be used to remove the control from the presentation:

.xforms-disabled {display: none}

In fact, because of CSS cascading rules, it is essential in this case to override the cascade:

.xforms-disabled {display: none !important}

Required and CSS

An element in the transformation contains an icon to be displayed if the value is required:

<span class="xforms-required-icon">*</span>

The default is not to display it:

.xforms-required-icon { display: none }

unless the value is required:

.xforms-required .xforms-required-icon {
    display: inline;
    margin-left: 3px;
    color: red


A credit card input

Validity and CSS

All information about presentation for invalidity is contained in the span element of class xforms-alert:

<span class="xforms-alert">
      <span class="xforms-alert-icon"> </span>
      <span id="xsltforms-mainform-alert-4_2_10_2_4_3_"
           >Not a valid credit card number</span>

Validity and CSS

Similarly to required, the default is only to display it for invalid values:

.xforms-alert { display: none }
 .xforms-invalid .xforms-alert { display: inline }

along with the alert icon:

.xforms-alert-icon {
   background-image: url(../img/icon_error.gif); 
   background-repeat: no-repeat;


An invalid credit card number

Using CSS properties, hovering over the alert icon pops up the alert text:

Hovering over an alert icon


For a coming new version, we are working on a number of improvements in the visual approach, as well as in the use of the CSS, and the format of the transformed HTML.

The aim is to make the default styling more attractive, and more flexible.

(What is presented here is work in progress.)

Styling of labels

For a start, labels will be styled bold, and by default above the control:

A basic control

This helps in lining up controls vertically and generally makes the style more restful to the eye.

This is simply done by making the label element a block, with bold font:

.xforms-label {font-weight: bold; display: block}

Styling of required

Although the transformed HTML contains a representation of the asterisk to be included, in the element with class xforms-required-icon, it gives more flexibility to ignore the required icon, and instead insert it from the CSS:

.xforms-required-icon {display: none}
 .xforms-required .xforms-label:after {content: '*'; color: red}


required credit card

This also means that in future the transformed HTML can drop the span element with class of required-icon.

Styling of validity

If a value is invalid, either due to its type or a constraint, using the same technique a large red X can be displayed after the label:

.xforms-invalid .xforms-label:after 
    {content: ' ✖'; color: red}


However, because of CSS cascading rules and the content property of CSS, if a value is both required and invalid a rule has to be added to match that case as well:

.xforms-required.xforms-invalid .xforms-label:after 
    {content: '*✖'; color: red}


For invalid input values, the background of the input field will additionally be coloured a light red:

.xforms-invalid .value input
    {background-color: #fcc; border-style: solid; border-width: thin}


Finally for invalid values the alert text has to be displayed. Normally alerts will not be displayed:

.xforms-alert-icon {display: none}
 .xforms-alert {display: none; position: relative;}

(Again the alert-icon element is no longer needed in the transformed HTML.)

On becoming invalid, the alert text can be popped up:

.xforms-invalid .xforms-alert {display: inline}
 .xforms-alert-value {
    color: white; background-color: red;
    margin-left: 0.5ex; padding: 0.2ex;
    border: thin solid black;

the end result being:


Styling Flexibility

Unfortunately, CSS in general doesn't allow the reordering of content, but nevertheless there is some freedom to how labels of controls can be positioned.

Since the label element is textually before the input field in the transformed HTML, it is easy to position the label above or to the left of the control. For instance, instead of above the control as in the last example, to the left:

   {display: inline-block; width: 12ex; text-align: right}


An input with the label positioned to the left of the control

Other label positions

With care, labels can be positioned to the right of the control, by floating the label element, or with even more care, below, using relative positioning.


To give the user some freedom in how XForms are displayed, but without having to know details of CSS, a skinning technique will be used.

This is where a top-level element is given classes that indicate presentation requirements of the enclosed content. For instance, the enclosing body element can indicate the positioning required for labels:

<body class="xforms-labels-left">


CSS rules then key off this value to provide different presentations for different cases:

.xforms-labels-top .xforms-label
    {display: block; margin: 0}

 .xforms-labels-left .xforms-label
    {display: inline-block; width: 20ex; text-align: right}

Thanks to containment hierarchy, this offers quite a lot of flexibility, since even in one XForm different sets of controls can be formatted differently:

<group class="xforms-labels-left">
<group class="xforms-labels-top">



Future Transformation

HTML5 allows you to define custom elements.

Although these wouldn't offer any additional functionality, transforming using them means that the transformed HTML can be kept far closer to the original XForm.

It also greatly simplifies the XSLT necessary to produce the transformation (currently a ten-fold reduction in size).

Example transformation

As an example, a control such as

<input ref="creditcard" label="Credit card number" 
       alert="Not a valid credit card number"/>

can now be transformed to

<xforms-input xf-ref="@creditcard">
    <xforms-label>Credit card number</xforms-label>
    <xforms-alert>Not a valid credit card number</xforms-alert>

The same CSS techniques can be applied to these elements.


XForms offers a lot of flexibility in how it can be implemented.

One of the advantages of implementing it by transforming to HTML means that the power of CSS is available for presentation ends.

However, to avoid requiring the XForms programmer to necessarily know CSS, skinning techniques can be used to offer flexibility to the presentations available.

A new XForms implementation is in preparation that will use those techniques.