Copyright ©2004 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
XForms is an XML application that represents the next generation of forms for the Web. This document specifies the requirements for XForms 1.1.
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.
This document will not be the final version - the Working Group may update the document when changes deemed necessary and appropriate as they develop XForms 1.1. Changes between this version and the previous version are illustrated in a diff-marked version .
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.
Requirement: Support SOAP as a new method of 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.
Some intended applications of XForms may require the ability to let the host document to have control over the XML data submitted to the server. A use case would be a document-centric system in which an entire XML document, not just the XML data is submitted.
Requirement: Allow the submission
element
to delegate submission serialization to the host document's
processor.
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).
Requirement: Let email address be a primitive (recognized) XForms datatype for schema data validation.
A document containing an XForms model can be associated with
externally defined XML data using linking attributes of the
instance
element, but there is no way to associate XML
data with externally defined documents that contain a compatible
XForms model. A use case would be to allow XForms processors to
edit XML obtained from the local computer or server, and to return
the edited XML to the local computer or server.
Requirement: A method of associating XML data with a container document that places the XML data in the document on load and persists the association in the XML data when it is submitted or saved.
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 X Y in XForms computational expressions.
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.
XForms actions benefit from access to key pieces of information available in the context of the events for which they are handlers.
Requirement: Allow an XForms action to access information in the context of the event for which the action was activated.
In XForms 1.0, textual content from
instance data nodes can be extracted
and rendered inline. For example, the output
element can
provide text from instance data to
the label
of a trigger
(which may
be rendered as text on the face of a button). XForms 1.0
has the facility to place
data in other media types, such as
digital images, into instance data in
a base 64 or hex binary encoding. As well, an instance node
may have a type identification
indicating that it contains a URI.
However, there is no facility in XForms 1.0 for inline rendition of
data in non-text media types.
Requirement: Allow facilities for inline rendition of non-text media types, both based on decoding data placed in an instance and on dereferencing a URI in instance data.
The ability to validate a credit card number is an important capability for better enabling online transactions to be performed using XForms. However, validating credit card numbers is difficult since they are not simply numbers but rather need to conform to a number of constraints, including valid prefixes, length, and adherence to the Luhn checksum formula.
Requirement: Provide the ability to indicate that an instance node represents a credit card number and provide the ability to determine whether the instance node content satisfies the validity constraints of a credit card number as defined in ISO/IEC 7812.
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.
To facilitate the adoption of XForms in other XML tag sets, which is stated as a key goal in the XForms 1.0 requirements , the conformance levels for implementations of XForms elements outside of the XForms model will be modified (because those elements must often be more closely integrated with the host language).
Requirement: Let the XForms user interface related elements and attributes be recommended.
There are many use cases in which a behavior should be followed
by closing the containing document (which may cause the user agent
to close if appropriate). For example, in XForms 1.0 the
replace="all"
setting on a submission
can
be considered to close the containing document as the user agent
displays the new document with the result data of the submission. A
more general facility is required to notify the user agent of the
need to close the containing document at any time, for example in
response to a trigger activation or other event.
Requirement: Increased ability for XForms markup to indicate the need to close the containing document.
This document was produced with the participation of current XForms Working Group participants: