The following is an overview of the new features and changed behaviors available in XForms 1.1. The text is taken from section 1.5 of the XForms 1.1 specification.

Model and Instance

The model element now must support a version attribute to help authors bridge the transition between XForms 1.0 to XForms 1.1.

The instance element now has a resource attribute that allows instance data to be obtained from a URI only if the instance does not already contain data. By contrast, the src attribute overrides the inline content in an instance. The resource attribute is more useful in systems that must support save and reload of XForms-based documents.

Enhanced Submissions

The submission element offers many new features that allow significantly improved data communications capabilities for XForms, including:

• Access to SOAP-based web services, RESTful services, ATOM-based services, and non-XML services
• Improved control over submission processing and serialization
• Ability to control the submission URI and headers with instance data
• Targetted instance data replacement capabilities

The submission element now has a resource attribute and resource child element that allow the instance data to dynamically control the submission URI. As a result, the action attribute is deprecated, though still supported in XForms 1.1. (See Specifying the submission URL and headers at run-time.)

In XForms 1.0, submissions were already more capable than AJAX, based on the ability to automatically update a form with results from HTTP and HTTPS services, including RSS feeds. In XForms 1.1, the method attribute now supports delete as well as any other QName. The method child element also allows the method to be dynamically controlled by instance data.

Submission headers can now be added, and even dynamically controlled by instance data, using the header child element. (See Specifying the submission URL and headers at run-time.)

These features complete the capabilities needed for ATOM and RESTful services.

XForms 1.1 also offers special submission header behavior through the mediatype attribute to allow communications with SOAP 1.1 and 1.2 web services.

The submission element now supports attributes relevant and validate, which allow form authors to turn off instance data relevance pruning and validity checking. This allows submission to be used to save and reload unfinished data on a server or the local file system.

The submission element now supports the targetref attribute, which allows partial instance replacement by identifying a node to be replaced with the submission result.

The replace attribute also now supports a text setting, which allows the content of the target node, rather than the target node itself, to be replaced with a non-XML (text) submission result.

The submission element now also supports the xforms-submit-serialize event, which allows the form author to provide a custom serialization, such as plain text or the full XForms document, as the submission data.

The serialization attribute also provides increased control over the submission data serialization, including the setting none, which allows submission to be used for simple URI activation.

The xforms-submit-done and xforms-submit-error events now have event context information available that provide more information about both successful and failed submissions, such as the response headers of successful submissions and the reason code for failed submissions.

Finally, over a dozen new examples have been added to illustrate submission usage.

Datatypes and Model Item Properties

XForms 1.1 now offers email and card-number datatypes so form authors can easily validate email address and credit card number input values.

To further simplify authoring, XForms 1.1 now also provides its own definitions of the XML Schema datatypes, except the XForms versions permit the empty string. Allowing empty string means that input like an age or a birthdate can be collected without being required input for validity (an empty string is not in the lexical space of XML schema datatypes like xsd:positiveInteger and xsd:date). If an input is required, the form author can still use the XForms versions of the datatypes in combination with the required model item property. The XForms datatypes also aid authoring by allowing type definitions to omit namespace qualification, e.g. type="date" rather than type="xsd:date", if the default namespace of the model is set to XForms.

The readonly model item property was defined to be an inviolate property of the data model. This means it cannot be violated by anything outside of the model item property system, including not just form controls but also XForms actions and instance data access from the DOM interface.

Functions and XPath Expressions

XForms 1.1 now contains many new functions that can be used in calculate and other XPath expressions to enable numerous features, including:

• basic date math and working with local dates and times: local-date(), local-dateTime(), days-to-date(), seconds-to-dateTime(), and adjust-dateTime-to-timezone()
• working with tabular data and parallel lists: current(), choose() and context()
• basic security capabilities: digest(), hmac(), and random()
• improved numeric and string processing: power(), is-card-number(), and compare()
• search across instances of a model: two parameter id() function
• access to context information added to many XForms events: event()

The specification now provides a better classification of binding expression types as well as a more rigorous definition for dynamic dependencies. These definitions ensure that XPath expressions in form controls and actions which use the index() are automatically re-evaluated when appropriate.

Due to the addition of the choose() function, the if() function is still supported but deprecated as futureproofing against the conflict with the if keyword in XPath 2.0.

User Interface

The behavioral description common to all form controls has been improved to indicate default layout styling and rendering requirements for required data.

The output form control has been improved to render non-text mediatypes, particularly images, obtained from instance data.

An example was added to show the use of a DOMActivate handler on an input to automatically initiate a submission once a user enters and commits input, such as a search query.

The processing model and implementation requirements on selection controls were elaborated upon to ensure consistency of behavior between selection data expressed as textual lists versus element lists.

The ability to create wizard-like interfaces with dynamically available form controls has been improved. Details are in the description of improvements to actions.

The specification provides more rigorous definitions and classifications of form controls, which have been applied throughout the specification to ensure proper support of varied features related to form controls, such as events, applicability of model item properties, and focusability.

The XForms repeat has been made more powerful and flexible. The specification now provides rigorous definitions and processing model descriptions for repeated content, including creation, destruction, IDREF resolution and event flow between repeated content and the containing content (which may itself be repeated). The repeat is now capable of operating over any nodeset, not just an homogeneous collection. A formal processing model for repeat index handling has been defined.

Actions and Events

The insert and delete actions have been converted from specialized actions associated with repeat to generalized data insertion and deletion operations. An entire appendix of 15 examples was added to illustrate this additional capability in detail.

All XForms actions, as well as sets of actions, can be executed conditionally or iteratively. Combined with the generalized insert and delete, this means that the information processing power of XForms 1.1 is Turing-complete.

The dispatch action now allows the event name and target to be specified by instance data. A new attribute, delay, has also been added to allow an event to be scheduled for dispatch at a later time. Since the event handler for the event can schedule same event for later dispatch, it is possible in XForms 1.1 to create background daemon tasks.

The setfocus and toggle have been improved to help with creating wizard interfaces and handling dynamically available content. The control to focus and the case to select can now be specified by instance data. These actions have also been improved relative to the recalculation processing model. They now perform deferred updates before their regular processing to ensure the user interface is automatically refreshed.

As part of the improvement to repeat index management, the setindex action now behaves more like setvalue, which means it now sets the flags for automatic recalculation, revalidation and user interface refresh. As well, this action now also performs deferred updates before its regular processing to ensure the user interface is up to date.

Finally, the setvalue action has been improved due to the addition of the context() function. Now it is possible to express the value attribute in terms of the same context node used to evaluate the single node binding. This improves the ability to use setvalue inside of a repeat to set values of instance nodes that are outside of the repeat nodeset based on values that are within the repeat nodeset.