Re: XForms submission: synchronous?

Hi Mikko,

Yes, I am calling out the issue to promote discussion because I think many 
of us believe it should be asynchronous so, exactly as you said, "the spec 
needs to be cleared" because the asynchronous implementations are not 
currently supported by it., whereas I think the intent was to leave it 
open to implementers.

Saying nothing about asynchronicity causes a step-by-step read of the spec 
in which the reader never gets to the point of branching.
The xforms:submit (or trigger with send action) begets xforms-submit 
begets the entire submission all the way to done or error.

One problem with saying nothing is that it leads to non-interoperability 
of forms without strong language from us that a send action should *not* 
be followed by any other actions.  The actions sequences would work on 
sychronous implementations and fail on others.

We also need to have a frank discussion of when in the submission process 
do we become asynchronous.  For example, if the whole of xforms-submit 
occurs on a separate thread, then we have problems if the user is able to 
further interact with the form between validation and sending the data. 
Whereas, if we say that only the actual send part goes asynchronous, then 
things are a lot better for us.

Either way, the point is that not only must we say *something* along the 
lines that submission MAY be asynchronous, but what we say matters, too.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Mikko Honkala <honkkis@tml.hut.fi> 
Sent by: www-forms-request@w3.org
06/15/2006 02:20 AM

To
John Boyer/CanWest/IBM@IBMCA, www-forms@w3.org
cc

Subject
Re: XForms submission: synchronous?







Hi John,

I don't agree that submission is synchronous in the spec. This is a bit 
unclear in the spec, although most implementers have implemented it 
asynchronously (similar to AJAX). There is text in the spec regarding to 
simultaneous ongoing submissions, which hint in the asynchronous 
direction.

The xforms-submit-done is the hook for the author.

In my opinion xforms:submit does not block. It just starts the 
submission and returns immediately. That has to be cleared in the spec. 
Most browsers are event queue-based anyway, so no two actions/scripts 
are ever run simultaneously, except for ongoing submissions.

-mikko

John Boyer wrote:
>
> Current XForms 1.0 reads that submission is synchronous
> because DOMActivate on trigger "dispatches" xforms-submit.
>
> The spec does not say "(may|should|must) launch a separate
> thread to dispatch" xforms-submit.
> 
> Then, xforms-submit capture, bubble and default processing
> occur.  The default processing then describes the occurrence
> of the entire submission down to done or error.
>
> Therefore, it is currently reasonable for an XForms author to
> assume that a send action which does an instance replacement
> will actually replace the instance before the next action after
> the send occurs.
>
> To be fair, it would be *better* for that author to write the follow-on
> actions after a send action into the xforms-submit-done handler
> in order to ensure that the follow-on actions occur only if the
> submission is successful.  And if this is done, then the resulting
> form would operate correctly whether submission is synchronous
> or asynchronous.
>
> Moreover, there's a lot of benefit to being asynchronous, and some
> implementations at least have already gone that route despite what
> the spec says, so this email is being sent to promote discussion
> about the issue so we can get alignment, either for 1.0 or 1.1.
>
> In particular, it was stated here at the FtF that the option of 
> synchronicity
> was deliberately left open so as not to preclude implementation on
> small devices.  So, clearly the language should be that a submissoin
> MAY be asynchronous.
>
> Moreover, if a submission is asynchronous, then how far into the
> process does it get while still blocking the initiating thread?  In 
other
> words, is the whole dispatch of xforms-submit done by a separate thread?
> Or do we only branch to a separate thread some time after taking a
> snapshot of the data to be submitted?   Otherwise, the sufficiently
> talented user could change the data between the point where we
> prune and validate and the point where the data is transmitted.
>
> John M. Boyer, Ph.D.
> Senior Product Architect/Research Scientist
> Co-Chair, W3C XForms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>