XForms 1.1 Requirements

W3C Working Group Note 26 January 2004

This version:
Latest version:
Previous version:
John Boyer, PureEdge Solutions Inc.
Roland Merrick, IBM
Sebastian Schnitzenbaumer, SAP


XForms is an XML application that represents the next generation of forms for the Web. This document specifies the requirements for XForms 1.1.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a W3C Working Group Note, made available by the W3C XForms Working Group as part of the XForms Activity within the W3C Interaction Domain. The authors of this document are the XForms Working Group participants.

The XForms Working Group Patent Disclosure page contains details on known patents related to this document, in conformance with W3C policy requirements.

Comments on this document are welcome. You may email comments to the appropriate public mailing list for the XForms Working Group: www-forms-editor@w3.org (Archive). Discussion of these issues will take place on the public mailing list www-forms@w3.org (Archive). Please note that comments that you make will be publicly archived and available, do not send information you would not want to see distributed, such as private data.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.



XForms 1.1 will build upon the solid foundation set forth by XForms 1.0 - the Next Generation of Web Forms. This version makes incremental improvements over version 1.0 to provide expanded behaviors for the existing and established XForms Model-View-Controller Framework and by embracing SOAP. This version also makes adjustments to XForms to facilitate its adoption in other host languages.

1. Client/Server Interaction

1.1 SOAP Integration

Requirement: Support SOAP as a new method of submission.

1.2 Improved Control over Submission

In XForms 1.0, the submission element allows sending part of any instance to the server, but there is no reciprocal functionality for handling the returned data. In particular, there is no ability to pass partial instance data back and forth between client and server based on conditions expressed via XForms model properties and/or triggered by user interactions.

Requirement: Allow the submission element to specify that the returned data can go in any instance, not just the instance from which the submitted data was drawn.

Requirement: Allow the submission element to specify that the returned data can be used to replace a node in the instance data. A use case would be submitting an element containing a UK postal code and having the returned data replace an instance subtree containing an address.

2. Incremental Improvements to XForms 1.0

2.1 Repeat/Insert Enhancements

In XForms 1.0, a repeat element creates the user interface elements in its content once for each node in the collection indicated by its nodeset attribute. If the nodeset expression results in an empty collection, then no user interface elements are created.

To dynamically add user interface elements as more data becomes available, insert is used to add another node to the collection to which the repeat nodeset is bound. However, the insert element in XForms 1.0 requires that the collection contain a prototypical node in the initial instance data that is to be duplicated in the collection.

Due to this architecture, it is not possible to use insert on a repeat collection that is initially empty. The use case for an initially empty collection is a shopping cart application, where the user expects to start with an empty shopping cart.

Secondly, it is also more difficult to express forms in which the data content is derived not from the prototypical instance but from other instance data obtained after initialization. Each leaf node in the subtree rooted by the new node in the repeat collection must currently be filled with a separate invocation of setvalue even if the desired subtree structure exists elsewhere in instance data.

Requirement: Allow a method for copying a subtree of instance data (identified by a single apex element node) and pasting the subtree copy into an identified instance element node. The method must provide a facility for indicating where to put the subtree copy in the children of the target node (e.g. first, last, after a given child).

2.2 Bind Attribute on Bind Element

The XForms 1.0 Schema currently allows bind elements to be nested. One capability of nested binds is that an outer bind can provide the XPath nodeset against which an inner bind operates to provide various model item properties.

In XForms 1.0, user interface elements can indicate an XPath node or nodeset using ref or nodeset. Alternately, a bind attribute can be used to indicate by IDREF a bind element whose whose XPath nodeset is to be used with the user interface element.

Other than the possible issue of referring to a bind in another model, a bind element should be able to reference another bind element to provide a starting XPath nodeset with the same effect as if the former bind had been nested within the latter.

Requirement:Allow a bind element to use a bind attribute to obtain its starting XPath nodeset from another bind element.

A use case for this requirement is to allow forms processing systems to separate business rules (the 'inner' binds that specify computed model item properties) from database rules (the 'outer' binds that specify data locations within the instance). Forms management systems could then construct forms more easily since the business rules could simply be concatenated to the database rules if the former referred to the latter by ID reference rather than having to be nested within them.

2.3 Email-address Datatype

Requirement: Let email address be a primitive (recognized) XForms datatype for schema data validation.

2.4 XForms Processor as XML Editor

XForms expresses a processing model and user interface for the modification of data expressed in XML. Currently, the XML can be obtained from within the document or from a server. It would be useful to allow XForms processors to edit XML obtained from the local computer, and to return the edited XML to the local computer. To avoid security issues, this cannot be done by simply using a file scheme in the src attribute of the XForms instance element.

Requirement: Allow an XForms processor to provide an XML editing capability.

2.5 Power Function

Applications that require mathematical exponentiation (raising X to the power Y) are not possible in XForms 1.0, such as the compounded interest calculation for a periodic loan payment.

Requirement: Allow the ability to calculate XY in XForms computational expressions.

2.6 Referencing Bind Sites in XPath Expressions

The ability to reuse the XPath node-set referenced by a bind has proven to be a valuable and powerful capability. For example, the XPath node-set referenced by a bind can be used by another bind or by a user interface element. It is useful to extend this referencing capability to XPath expressions.

Requirement: Allow the ability to obtain the XPath node-set associated with an identified bind from within an XPath expression.

2.7 Improved Search for Instance Data by Key Value

In some forms, it is necessary to perform a simple table lookup based on user input. For example, suppose a form contains an element conversionTable that provides conversion rates for various currencies to the user's local currency. Based on the conversion selected by the user, the appropriate exchange rate would be used in a calculation.

XPath provides the ability to perform this type of search using predicates. To continue the above example, suppose each child of conversionTable is a rate element with the exchange rate as content and a currency attribute. Further, let a separate instance element called currency provide the storage for the currency selected by the user, and let amount contain the amount to convert. The converted amount could then be obtained using the following XPath: /root/amount * /root/conversionTable/rate[@currency=/root/currency].

The problem with this approach is that it uses absolute referencing to obtain the currency value selected by the user. If the converted amount, amount, and currency elements were moved to a deeper point in the instance data, then the XPath would have to be rewritten.

Requirement: Allow an XPath expression to perform a table search using a key whose value is referenced relative to the initial context node of the XPath expression.

3. Better Integration to Host Languages

3.1 Simplify Authoring XForms in XHTML2

To increase widespread adoption of XForms in web applications, it is necessary to reduce the difficulty of authoring XForms in XHTML, which is currently hindered by the incessant need to flip between the host language namespace and the XForms namespace when authoring the user interface component of a form.

Requirement: Simplify Authoring XForms in XHTML2.

3.2 XForms Model as Distinct Conformance Level

To facilitate the adoption of XForms in other XML tag sets, which is stated as a key goal in the XForms 1.0 requirements, implementation support for the XForms model will be a conformance level formally recognized by a distinct namespace from the XForms user interface related elements and attributes.

Requirement: Let the XForms 1.1 namespace be applied to the XForms 1.1 model, and let the XForms user interface related elements and attributes be defined abstractly so they can appear in a separate namespace or in the namespace of each host language.

A1 Acknowledgments

This document was produced with the participation of current XForms Working Group participants: