Although submission is a powerful feature of version 1.0 of XForms, there are a number of common use-cases that it is unable to support. For example, although it's easy for an XForms 1.0 form to request an RSS feed and to display the data with a repeat, it's not possible for the user to specify the feed location at run-time, perhaps by typing a URL into an input control, or selecting from a list. XForms 1.1 adds a number of new features to submission to control the URL, request headers, location of returned data, and more, which together make it much easier to build forms that use servers based on REST, ATOM, SOAP, and WebDAV.
In addition to the RSS feed example, other configurations that require URIs to be defined at run-time include REST-based services. For example, Basecamp incorporates the user's name into the URL, and as such it is impossible to create a generic form with XForms 1.0, even though XForms is ideal for communicating with such services.
Perhaps the most important example of a service that can't be used with XForms 1.0 is ATOM. Whilst at a push a form could be created to provide support for Basecamp (by creating one form per person!) there is simply no workaround that would allow ATOM to be used, since the URL that should be used for adding and editing items is provided within the item itself (a process called introspection).
Just as important as setting the URL at run-time is the need to specify request headers; both WebDAV and SOAP, for example, require header values to be set, as does HTTP authentication. (Whilst most XForms processors support HTTP authentication using the usual pop-up login box, by being able to set headers on a request it's possible for a form author to create their own login mechanism.)
A good example of the need for headers is when making a SOAP request. The action to be performed on the server is usually passed as a header in the HTTP request. Using the XForms 1.1 additions, this could be configured as follows:
<xf:submission
ref="instance('inst-request')"
method="post"
replace="none"
>
<xf:resource value="instance('inst-control')/submission/@action" />
<xf:header>
<xf:name>SOAPAction</xf:name>
<xf:value value="concat(
'"http://schemas.xmlsoap.org/wsdl/http/',
local-name(instance('inst-request')/soap:Body/*),
'"'
)"
/>
</xf:header>
</xf:submission>
One nice feature of this example is that the 'method' to use in the SOAPAction header is calculated for us automatically from the actual SOAP payload.
Whatever technique is used to get the URI into the submission, a little trick you can use to allow the user to choose a file is to use the xf:upload control to obtain a URL, as follows.
First, create a submission that uses a dynamic URL:
<xf:submission
ref="instance('inst-request')"
method="post"
replace="none"
>
<xf:resource value="instance('inst-control')/submission/@action" />
</xf:submission>
Next give the node that will hold the URL a datatype of 'xsd:anyURI', so that it can be used with the xf:upload control:
<xf:bind nodeset="instance('inst-control')/submission/@action" type="xsd:anyURI" />
Finally, use an xf:upload control to allow the user to provide a URL:
<xf:upload ref="instance('i-config')/submission/@action">
<xf:label>Choose file</xf:label>
</xf:upload>
The xf:upload control is often used to 'upload' the contents of a file into the instance data, but by binding the control to a node that has a datatype of xsd:anyURI we tell the control that all we want is the URL for the file, and not the file itself.