Abstract

HTML Forms are the weakest part of many Web interfaces, they provide limited datatype support, and require a lot of scripting for implementing user-friendly interfaces. XForms are a new technology for form-based data input with a clear separation of data and user interface issues. This way, XForms support device-neutral data input, where devices have a certain degree of freedom for presenting forms and acquiring input data. In addition, XForms are using XML as input and output format, thus making integration into XML-oriented environments easier.

HTML Form Problems

• HTML Forms are the only form of Web-based data input
  • the number of input elements is very limited
  • non-scripted input requires roundtrips in case of errors
  • data entry is tightly coupled to the input control
  • data input/output is not well-integrated
• HTML forms are passive client-side controls
  • text, selections (single, multiple), file upload, submission
  • any client-side action must be implemented by scripting
• Form input and output is not very Web-like
  • initial form data must be part of the form markup
  • final form data is transmitted using HTTP GET or POST
  • final form data uses a special URI-oriented encoding
  • data conversion often disrupts an otherwise smooth flow of information

XForms for XML-oriented Web Forms

• Data should be represented in XML
  • XForms accept initial form data in XML documents
  • XForms produce the final form data as an XML document
• XForms define the data model in XML
  • data goes in and out of the form as XML documents
  • data can be used for validation, computation, and interactions
• XForms must be supported as a client-side technology
  • applications produce XForms-oriented interfaces
  • they expect to get the XML-in/XML-out behavior of XForms
  • XForms adoption so far has been disappointing
• XForms can be implemented as a reverse proxy
  • the application server sends the form to an XForms server
  • the XForms server generates HTML code and scripting support
  • upon form completion, the XForms server sends the XML to the application server

HTML Forms and XForms

XForms and XSLT

XSLT	XForms

XForms Browsers

• Firefox supports XForms through an extension
  • currently not available for Firefox 2
  • only few users can be expected to have the extension installed
  • the extension is in an early stage of development (currently 0.7)
  • if successful and stable, it may become an integral part of the browser
• IE probably will never natively support XForms
  • Microsoft has a (somewhat) competing technology with Infopath
  • the overlap seems to be big enough to keep Microsoft from supporting XForms
  • XForms support can be added using plug-ins, e.g. the formsPlayer ActiveX control
• XHTML 2.0 uses XForms
  • XHTML 1.0 is HTML 4.01 in XML
  • XHTML 1.1 is an attempt to modularize XHTML (turn HTML into a language family)
  • XHTML 2.0 is a rather radical redesign of (X)HTML, it may very well fail
  • if XHTML 2.0 succeeds, client-side XForms may become the norm

Server-Side XForms

• XForms-based applications define their interactions in XForms
  • declarative specifications are better than writing code
• Reverse proxies replace XForms pages with HTML forms
  • application development can be based on XForms abstractions
  • application deployment does not depend on XForms availability
• XForms functionality has to be built into scripted HTML forms pages
  • this approach works with any HTML browser
  • but only as long as the scripting is perfectly cross-browser compatible
• Robust cross-browser scripting is difficult and brittle
  • new releases and configuration options can easily break scripts
  • testing only covers a fraction of the possible browser/OS/version/configuration combinations
  • scripting will most likely have problem on certain platforms
  • fixes must be implemented in the XForms engine, not in the application

Client-Side XForms

• XForms has been designed as a client-side technology
  • XForms support should be part of a standard Web client
  • XForms can then be delivered directly to the client
• XForms so far has not gained a lot of traction
  • even the open source community have to really embraced XForms
  • Microsoft's has a competing technology and little incentive to push XForms
  • XForms on mobile devices are not a reliable deployment platform
• XForms currently faces the hen and egg problem
  • why invest in XForms when there are few clients supporting it?
  • why support XForms in clients when nobody uses them?
  • Server-Side XForms may create a wrong image (a server-side technology generating lots of scripting)

Data and Forms

• Data often is collected in a form with an underlying data model
  • the interface should not necessarily directly reflect this data model
  • ideally, the data model should be completely independent from the interface
• Not all XML Schemas can be used with XForms
  • mixed content is not supported at all
  • it is not possible to manipulate a mixed list of data items
  • XForms rely on the idea of repeated similar (structurally identical) items
• XML Schemas must be designed to work with XForms
  • for simple schemas, this might not create any trouble
  • for complex schema, this might by almost impossible
  • one possible solution is an intermediate transformation step

Hello World in XForms

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms">
 <head>
  <title>Hello World XForms</title>
  <xf:model>
   <xf:instance>
    <first-name xmlns="" />
   </xf:instance>
  </xf:model>
 </head>
 <body>
  <p>Please enter your first name:
   <xf:input ref="/first-name" incremental="true" />
  </p>
  <p>
   <xf:output value="if (normalize-space(/first-name) = '') then '' else concat('Hello, ', /first-name, '!')" />
  </p>
 </body>
</html>

Submission

• HTML forms are always replaced with a new document
  • after pressing submit, the form values are transmitted to the server
  • the server's response completely replaces the form in the browser
• XForms have greater flexibility in interacting with a server
  • they may use HTML's model of completely replacing the form
  • replace="instance" will only replace the instance (sequential editing)
  • replace="none" will not replace anything (sequential creation, multi-submit forms)

<model><instance><data xmlns=""><accountnumber/><name/><address/></data></instance>
 <submission method="get" action="…/prefill" id="prefill" replace="instance"/>
 <submission method="put" action="…/change" id="change" replace="none"/>
</model>
…
<input ref="accountnumber"><label>Account Number</label></input>
<submit submission="prefill"><label>Find</label></submit>
<input ref="name"><label>Name</label></input>
<textarea ref="address"><label>Address</label></textarea>
<submit submission="change"><label>Submit</label></submit>

User Friendliness

• XML Schema data types and user data entry
  • XML Schema has the lexical space (the characters appearing in an XML document)
  • XML Schema has the value space (the concept represented by the characters)
  • XForms introduce the user space (a representation appropriate for user interactions)
• Calendars dates are a very good example for user friendliness
  • MM/DD/YY or DD.MM.YY or YYYY-MM-DD are all not very user friendly
  • presenting a little calendar makes date selection much easier
• Number input illustrates all of the above concepts
  • the value space defines which values are allowed for a field (e.g., between 0 and 20)
  • the lexical space may allow variations of the value representation (5 and 05 represent the same value)
  • Range values can be most easily entered using a slider

Model and Interface Separation

Models

• XForms follows the MVC (Model/View/Controller) pattern
  • the XForms Model has the part of the M
  • Controls take the role of the V
  • there is no direct analogy to the C (processing model and events)
• XForms uses the XPath data model
  • a model element contains information about the XForms model
  • instance data can be embedded in the XForms document
  • instance data can be referred to by the XForms document
• XForms model data is not under control of the XForms
  • it can be used as the initial input for a form
  • it can be edited and submitted
  • it should not have any specific XForms markup in it
  • any XForms-specific properties are set with Bindings

Bindings

• Bindings allow the definition of model properties
  • make assertions with readonly, required, relevant, calculate, and constraint
  • all of these assertions use XPaths and are dynamically re-evaluated
  • it is possible to hide the model behind bindings and only use these for Controls
• Bindings connect Controls and Models
  • input bind="…" … / references a binding from a control
  • input ref="…" … / directly references a node in the instance (using an XPath)
  • referencing bindings is more indirect and more stable (no direct model dependency)

   <xf:bind nodeset="/data/one" id="one" type="xs:integer" />
   <xf:bind nodeset="/data/one" relevant="/data/two != 42" />
   <xf:bind nodeset="/data/two" id="two" type="xs:integer" />
   <xf:bind nodeset="/data/two" readonly="/data/one = 42" />
   <xf:bind nodeset="/data/three" id="three" calculate="/data/one + /data/two" />
   <xf:bind nodeset="/data/four" id="four" required="/data/three = 42" relevant="/data/three = 42" type="xs:date" constraint="starts-with(text(), '2007')"/>

User Interface Elements

• XForms controls specify the appearance of the data model interface
  • most controls are similar to the controls in HTML forms
  • XForms specifies some new controls for user interface elements
  • other languages or devices could specify different sets of controls
  • a control is simply a way of getting model data from the user
• There is no 1:1 correspondence of model and control
  • parts of the model might not be presented at all
  • parts of the model may only be used for Output
  • parts of the model may be calculated, but not directly entered
  • parts of the model may have multiple controls associated with them

Input

• Basic input of individual values
• Normally displayed as a text box
• Datatype specifications can be used for better usability
  • the exact set of supported datatypes is specific to the client
  • even if types are not used for entry, they must be used for validation

   <xf:input bind="one" incremental="true" />
   <xf:input bind="two" incremental="true" />
   <xf:input bind="three" incremental="true" />
   <xf:input bind="four" incremental="true" />

Secret

• Hidden text entry for passwords
  • has no security features other than hiding text display
  • real security must be implemented using HTTP over SSL (HTTPS)

   <xf:secret bind="four" incremental="true" />

Textarea

• Also very close to its HTML counterpart
• Type checking is done in the same way as for Input
  • but textareas will almost always contains just strings (longer texts)
  • the most likely restrictions will be minimum and maximum lengths

   <xf:textarea bind="one" incremental="true" />
   <xf:textarea bind="two" incremental="true" />
   <xf:textarea bind="three" incremental="true" />
   <xf:textarea bind="four" incremental="true" />

Output

• Generates values as part of the document content
  • generated content is indistinguishable from other content
  • but it will be updated when the associated value is updated
• If required, the generated value can be computed
  • the value attribute accepts any XPath as content
  • the XPath's string value will be the generated value

   <xf:output bind="one" incremental="true" />
   <xf:output bind="two" incremental="true" />
   <xf:output bind="three" incremental="true" />
   <xf:output bind="four" incremental="true" />
   <xf:output bind="four" value="string-length(.)" incremental="true" />

Upload

• HTML allows file selection and upload
  • this assumes that the data is available as a file in the file system
• XForms generalizes the idea of upload beyond file upload
  • data may come from any local source, for example a camera or a microphone
  • this is highly device-specific and not very well defined in the specification

   <xf:upload ref="/data/five">
    <xf:label>General Upload: </xf:label>
    <xf:filename ref="@filename"/>
    <xf:mediatype ref="@filename"/>
   </xf:upload>
   <xf:upload ref="/data/five" mediatype="image/*">
    <xf:label>Image Upload: </xf:label>
    <xf:filename ref="@filename"/>
    <xf:mediatype ref="@filename"/>
   </xf:upload>
   <xf:upload ref="/data/five" mediatype="audio/*">
    <xf:label>Audio Upload: </xf:label>
    <xf:filename ref="@filename"/>
    <xf:mediatype ref="@filename"/>
   </xf:upload>

Range

• Ranges are a new control for XForms
  • available for any data type which is a sequentially ordered type
  • can be represented as slider, rotary control, or edit box with spin controls
• Ranges cannot be mapped to normal HTML controls
  • this makes it difficult for Server-Side XForms to work reliably
  • if the scripting has a problem, the usability of the form maybe compromised

   <xf:range bind="one" start="0" end="10" incremental="true"><xf:label>0-10</xf:label></xf:range>
   <xf:range bind="one" start="0" end="50" incremental="true"><xf:label>0-50</xf:label></xf:range>
   <xf:range bind="one" start="0" end="100" step="10" incremental="true"><xf:label>0-100@10</xf:label></xf:range>

Trigger and Submit

• Similar to the generalized button of HTML forms
  • not a direct correspondence with any data in the model
  • used as a trigger to activate XForms actions
• Triggers can be bound to the model
  • useful if the trigger needs to be enabled/disabled
• Submit is a specialized version of the trigger
  • it triggers a submit action specified in the model

   <xf:trigger bind="one"><xf:label>Button</xf:label></xf:trigger>
   <xf:trigger bind="six"><xf:label>Button42</xf:label></xf:trigger>
   <xf:submit submission="save"><xf:label>Save as...</xf:label></xf:submit>

Select1

• Generalizes HTML's checkboxes, radio buttons, and selection lists
  • represents any choice where exactly one item should be picked
• Clients are free to choose the best representation
  • XForms authors may make suggestions using appearance
  • most clients will use the representations shown in examples
• selection may be specified as open
  • open selection allows users to enter other than the predefined values

   <xf:select1 bind="one">
    <xf:label>Default: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select1>
   <xf:select1 bind="one" appearance="full">
    <xf:label>Full: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select1>
   <xf:select1 bind="one" appearance="compact">
    <xf:label>Compact: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select1>
   <xf:select1 bind="one" appearance="minimal">
    <xf:label>Minimal: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select1>

Select

• Equivalent to HTML's select with multiple set
  • allows multiple selection from choices
  • the resulting value is a space-separated list of individual values
  • ideally, this control should be bound to an XML Schema list type

   <xf:select bind="one">
    <xf:label>Default: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select>
   <xf:select bind="one" appearance="full">
    <xf:label>Full: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select>
   <xf:select bind="one" appearance="compact">
    <xf:label>Compact: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select>
   <xf:select bind="one" appearance="minimal">
    <xf:label>Minimal: </xf:label>
    <xf:item><xf:label>One</xf:label><xf:value>1</xf:value></xf:item>
    <xf:item><xf:label>Two</xf:label><xf:value>2</xf:value></xf:item>
    <xf:item><xf:label>Three</xf:label><xf:value>3</xf:value></xf:item>
    <xf:item><xf:label>Four</xf:label><xf:value>4</xf:value></xf:item>
   </xf:select>

Common Controls

• Labels can be attached to all controls
  • their values can be hardcoded, Output generated, or read from an XML document
• Help, Hint, and Alert
  • helpful text as modeless messages, hints in the form, and alerts for validation errors
• Navigation Order and Keyboard Shortcuts
• Incremental
  • propagates update events on every change, not just when leaving the control

   <xf:textarea bind="data" incremental="true">
    <xf:label>Your Message (characters remaining: <xf:output bind="length"/>)</xf:label>
    <xf:help>Enter the message text you wish to send as an SMS message.</xf:help>
    <xf:hint>Message text</xf:hint>
    <xf:alert>Additional characters will be truncated!</xf:alert>
   </xf:textarea>

Beyond Static Forms

• Controls allow only static structures
  • they can be placed anywhere within Web pages
  • they allow better features than HTML forms
  • but they cannot cope with flexible forms
• More flexibility requires more dynamics
  • user interactions must be accessible in the form of Events
  • upon an event, XForms must be able to perform Actions

DOM Events

• Events are supported through on* attributes in HTML
  • the attributes contain scripting code (usually JavaScript)
  • connections between observers and handlers are hidden in the code
• XForms uses XML Events
  • XForms defines standardized even handlers, which are called Actions
  • if declarative event handling is not sufficient, it is possible to use scripting
  • for most applications, scripting is not required at all, everything can be handled declaratively

Declarative Calculator

Calculator Code

     <screen>0</screen>
     <screenbuffer>0</screenbuffer>
     <first>0</first>
     <second>0</second>
     <memory>0</memory>
     <result />

     <xf:trigger>
      <xf:label>4</xf:label>
      <xf:action ev:event="DOMActivate">
       <xf:setvalue ref="/equation/screenbuffer" value="/equation/screenbuffer * 10 + 4" />
       <xf:setvalue ref="/equation/screen" value="/equation/screenbuffer" />
      </xf:action>
     </xf:trigger>

     <xf:trigger>
      <xf:label>+</xf:label>
      <xf:action ev:event="DOMActivate">
       <xf:setvalue ref="/equation/first" value="/equation/screen" />
       <xf:setvalue ref="/equation/screenbuffer" value="0" />
       <xf:toggle ev:event="DOMActivate" case="add" />
      </xf:action>
     </xf:trigger>

     <xf:switch>
      <xf:case id="add">
       <xf:trigger>
        <xf:label>=</xf:label>
        <xf:action ev:event="DOMActivate">
         <xf:setvalue ref="/equation/second" value="/equation/screenbuffer" />
         <xf:setvalue ref="/equation/result" value="/equation/first + /equation/second" />
         <xf:setvalue ref="/equation/screen" value="/equation/result" />
         <xf:setvalue ref="/equation/screenbuffer" value="0" />
        </xf:action>
       </xf:trigger>
      </xf:case>

Better Forms

• XForms allow better forms to be developed
• XML-orientation makes life easier for XML-centric architectures
• Device-independence allows better separation of concerns
• XForms allows more declarative forms, less scripting required
  • current implementations are often Server-Side XForms: scripting again!
  • Server-Side XForms can be hard to debug (XForms/Script/Browser error?)
• XForms have some acceptance in vertical scenarios
  • widespread horizontal acceptance has not yet happened
  • possible killer apps are mobile applications or XHTML 2.0