Repeats and web service submissions don't work well together

Suppose you want to collect some data D comprised of one or more parts, 
where the validity of D is determined by a server-side rules engine.

The idea is to send D to a web service that runs the rules engine and 
returns true or false response for validity. 

The response can be placed back into D, at which point a trivial xforms 
constraint can ensure D is not submitted, e.g.
<bind nodeset="D" constraint="boolean-from-string(@valid)"/>

Now take this whole concept and stick it in a repeat.  It should not be 
much more difficult, but it is because submissions are not able to use any 
context from the point of invocation to obtain the request data or to 
indicate where the response data should go.

A pile of duct tape and baling wire can be used to cobble together a 
solution that usually works. 

What we're doing right now is using a trigger that has some actions before 
the send action to copy data to a "request" instance.  However, the send 
is asynchronous, so the only real hook we have for dealing with the 
response is xforms-submit-done.  As a result, a piece of context like "put 
the response on the Kth occurence of D" is lost.  To account for this, 
we're using an additional setvalue before the send to store the repeat 
index.

This usually works, but if the web service takes a little bit of time, 
then the user could theoretically delete the row while the submission is 
in progress.  Or they could insert another repeat item earlier in the 
repeat.  Either way the submission result will be copied to the wrong data 
node as a result.

The form author could put extra duct tape in place to account for repeat 
table mutations or simply to make the repeat data immutable while the 
operation is in progress, but this consists of finding their own inserts 
and deletes and doing a conditional patch.

Anyway, suffice it to say that we could use a mechanism in which the 
submission ref and target nodes could be given as xforms-submit event 
context info.  When processing submission results, the condition of a 
deleted target node could be handled in some way, of course, and there 
would be no problem with insertions really.  The act of doing this 
verification web service would reduce to calling a specialized send action 
that allowed us to set more of this stuff in the context of the send 
action rather than the context of the submission.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw