In the final day of the XForms face-to-face meeting today, we made great progress for XForms 1.1 defining synchronous or asynchronous submission.
A number of current implementations of XForms 1.0 perform instance data relevance pruning and validation followed by initiation of the data submission. The upload and download of octets occurs asynchronously, and when completed, the xforms-submit-done or xforms-submit-error is dispatched. However, the current recommendations for (DOM2) XML events and XForms actually describe a synchronous procession that starts with dispatching an xforms-submit through fives steps of default processing from relevance pruning and data validation all the way through to completion and dispatch of xforms-submit-done or xforms-submit-error.
A difference of behavior occurs when an action sequence contains a
send action followed by other actions. If the submission is synchronous, then the form author can expect that the actions after the send are able to operate over the data returned by the submission. For an asynchronous implementation, the send action returns before the new data arrives.
In reality, form authors should put the follow-on actions after a send into a handler for the xforms-submit-done event, since actions over data should only be run if the submission succeeds. Still, what's a working group to do?
We'll be adding a new attribute, probably called mode and probably having the value synchronous or asynchronous, so that the form author can choose which behavior is best. The synchronous behavior will have other advantages like suspending user interaction with form controls, but the default will undoubtedly be asynchronous.
Meanwhile, XForms 1.0 authors, get into the habit now of putting actions that operate over submission response data into the xforms-submit-done handler, not after a send action.[Read More]