- From: John Boyer <boyerj@ca.ibm.com>
- Date: Mon, 4 Apr 2011 13:56:43 -0700
- To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
- Cc: public-forms@w3.org
- Message-ID: <OFA096D6D6.57A5E1C4-ON88257868.0071492F-88257868.0073171A@ca.ibm.com>
It may be that "single concurrent submission" made it easy to untangle the responses, but I've never actually heard that offered as the example of why we kept the feature, so I think the transaction ID proposal won't fix the issue we were solving when we kept that feature. As far as I can recall, the rationale was user-centric. It is easy to make a form that avoids multiple submission initiated by user impatience or user error. Since there is currently no real submission progress indicator, a user may be inclined to press a submit or trigger a second time to activate a submission. Or the user may just hit the submit or trigger twice as a slip of the finger. Either way, the part of activation most likely to be associated with a billable event is the submission, and the current design ensures the user is not billed multiple times. It's not that submission is the ideal place to make the restriction, so lifting the restriction could be fine if it were done in tandem with adding an *easy* way to prevent submit *and* trigger controls from running multiple submission transactions. Cheers, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria 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 From: "Klotz, Leigh" <Leigh.Klotz@xerox.com> To: <public-forms@w3.org> Date: 04/04/2011 11:51 AM Subject: Re: Submission Request-Response IDs (concurrent submit) Sent by: public-forms-request@w3.org Nick van den Bleeken wrote: >Currently the XForms spec doesn't allows this 'Under no circumstances can more than a single concurrent >submit process be under way for a particular XForms submission' Yes, that was there before the asynchronous submission, but when asynchronous submission became part of the spec we retained it, partially because of the issue that you cannot untangle the responses. The transaction ID proposal is part of the fix. Leigh.
Received on Monday, 4 April 2011 20:57:18 UTC