Asynchronous submission responses are currently not matched up with their requests. We should have a way to match them up.

Use Cases

Response Order in success case

An asynchronous submission does a GET request of a Calendar entry, followed by another Get request for a second calendar entry, both using the same submission element. Both responses come back, but order isn't guaranteed, so unless the underlying data indicates the Calendar entry date, there's no way to match them up.

Response Order in mixed success/failure case

An asynchronous submission does a GET request of a Calendar entry, followed by another Get request for a second calendar entry, both using the same submission element. One of the responses comes back with an entry, and the other comes back as a "404 Not Found' error. Since order isn't guaranteed, we don't know if the Calendar entry was created and then deleted or was not existing and then created.

Long delayed responses

An asynchronous submission does a GET request of a Calendar entry, and it takes a long time to come back. When it comes back, we don't know when it was requested, so we don't know if the Calendar event is still relevant.

Submission Throttling

A form control submits on each xforms-value-changed event, but the events happen more frequently than the submission responses, causing backup and slowness. There should be an easy way to throttle submissions based on the existence (or possibly count) of outstanding un-responded requests.

Response placement

Although returned data can be used to determine disposition of response data, in some cases the necessary data is not present in the response, so knowledge of which request the response is for may be necessary. This can happen either with repeated submissions or with submission/resource/@value.

Requirements

There should be a way to determine for each submission response, which occurrence of the submission request initiated it.
The feature should not incur cost on those not using it.
The feature should not incur undue cost on implementations.
The feature should be implementable in split-agent XForms processors, and implementable using XHR.
The feature should support easy assignment of transaction-ids (or whatever identifier is used).
The feature should support easy authoring for association of existing instance data with a request/response pair (i.e., through a simple XPath predicate at most).
The feature should support easy authoring for query from action/@if (for submission throttling).
The feature should be backward compatible with XForms 1.1.

XForms 1.1 Considerations

XForms 1.1 does not allow multiple outstanding submissions for the same submission element, adding request-response IDs will allow us to relax that constraint, and allow authors to use @if on action to compare and selectively allow or cancel an xforms-submit action.

We should have an optional attribute on submission which enables multiple outstanding submissions and may also participate in defining the request/response ID in some way, if something other than a boolean enable/disable is required.

Implementation Considerations

HTTP already provides a correct mapping between requests and responses. XHR already provides this, by calling the correct function object on response. So both split-agent and XHR implementations should be OK. Other protocols supported by submission might not support it. (file: is OK because it's presumably synchronous.)

Libraries such as YUI provide a transaction id facility: http://yuiblog.com/sandbox/yui/v090/connection/docs/YAHOO.util.Connect.html#_transaction_id

Straw Proposal

Associate a non-negative integer transaction-id with each submission occurrence.
Put the number into the event('transaction-id') context information for the xforms-submit, xforms-submit-done, and xforms-submit-error events.
Add a new event, xforms-submit-replace-instance, whose default processing is to determine where to place the response data, and have it be responsible for evaluating submission/@targetref. Thus, event('transaction-id') will be available during evaluation of @targetref.

More Considerations

Should it be possible to query a transaction-id and see if it has completed?
Can Cancel a Submission be far behind?
Should transaction ids be UUID, sequence number, or undefined?