The changes between XForms 1.0 and XForms 1.0 Second Edition are documented in the next section, although the only one that would affect deployed forms is the way that MIP events are dispatched.
A separate section also lists the changes that have ocurred in formsPlayer, but the most significant is that there are a couple of changes to submission.
For many of your forms the fact that submission is now asynchronous will not require a change, since it was already good practice to not execute code after a send. Take the following example:
<xf:action ev:event="my-event"> <xf:send submission="sub" /> <xf:setvalue ref="x" value=". + 1" /> </xf:action>
In previous versions of formsPlayer with synchronous submissions, the setvalue would not be executed until the submission had completed. However, there is no way to know whether the submission was successful or not. In some situations this may be ok, but in others--perhaps a case is toggled so that some search results can be shown--it is not, since if the submission fails there will be nothing to see.
So even with synchronous submission it was better to put the code that comes after the send into an xforms-submit-done handler:
<xf:action ev:event="my-event"> <xf:send submission="sub" /> </xf:action> <xf:action ev:observer="sub" ev:event="xforms-submit-done"> <xf:setvalue ref="x" value=". + 1" /> </xf:action>
Now the setvalue will only take place if the data was correctly returned.
If your code already took this approach then you having nothing to change to take advantage of asynchronous submissions. But if it didn't you may see slightly different behaviour since actions following the send will now occur straight away. So toggling a case in a switch, for example, may not be desirable if the form then sits waiting for data to arrive.
For an example of how to make use of this to show an 'in progress' animation, see The Toggle action in the Introduction to XForms.
To give the author more control over how errors are handled there is now no longer a default error message for a failed submission. This can be confusing to a user if you don't have a handler for xforms-submit-error in your forms. In the past this would have been handled by formsPlayer showing a default message, but since this would often conflict with any message that the form author might have added themselves we decided to remove it. It's therefore a good idea to add something like the following to your forms:
<xf:action ev:observer="sub" ev:event="xforms-submit-error">
<xf:message level="modal">
Failed to update the customer details.
</xf:message>
</xf:action>