incremental delay considered harmful

[This is in response to ACTION-1786: 
http://www.w3.org/2011/03/23-forms-minutes.html#action02 ]

At least two XForms Processor implementations have added @delay to form 
controls, and use it to control how frequently @incremental=true 
controls dispatch xforms-value-changed events.

We've discussed a proposal to add this to XForms 1.2 three times, and 
each time have come to the conclusion that it is unnecessary.  However, 
we've decided to write up a set of use cases and how we believe they are 
already answered by XForms 1.1 facilities.  If you believe that the use 
cases aren't answered, or if there are other significant use cases, 
please let us know.  If you believe the implementation techniques 
described below are incorrect or too difficult, please let us know.  
Otherwise we'll assume that there is no need to add @delay to form 
controls, and that implementations will eventually drop the extension in 
favor of the techniques similar to those described below, or other 
techniques which preserve system performance without requiring form 
authors to use non-interoperable extensions.

XForms processor vendors might choose to provide implementation of 
customizing the behavior of incremental, but the default behavior should 
be one of reasonable performance, and should /not/ result in an 
immediate dispatch of xforms-value-changed for every keystroke.

Use case: server-side completion
input/@incremental='true' is used with an xforms-value-changed event 
handler which dispatches send to an asynchronous submission.  Submission 
responses are used to update the itemset of an accompanying xf:select1.  
If the user types too fast and the asynchronous submission takes too 
long, or if pre-submission processing takes too long, system performance 
may suffer.  @delay='200' might offer a time interval for dispatch of 
xforms-value-changed events.

Use case: xslt transformation
input/@incremental='true' is used with an xforms-value-changed event 
handler which dispatches an event to cause an XSLT transformation to 
take place.  If the user types too fast and the XSLT transformation 
takes a long time, system performance may suffer.  @delay='200' might 
offer a time interval for dispatch of xforms-value-changed events.

XForms 1.1:
XForms 1.1 does not require that xforms-value-changed be dispatched on 
every keystroke.  (In fact there might not even be keystrokes, depending 
on the user interface medium.)

Discussion of Implementation Techniques:

Erik Bruchez points out that Orbeon offers a simple heurstic-based 
approach for how often input/@incremental dispatches 
xforms-value-changed in a desktop user interface:  Each time the user 
types a character, if an xforms-value-changed event has been dispatched 
more recently than X milliseconds, do not dispatch the event, otherwise 
do dispatch the event.  If the user stops typing for more than Y 
milliseconds, dispatch the event.  The numbers X and Y should be 
determined by the XForms Processor itself based on its own performance 
metrics.

XForms processor vendors might choose to provide implementation specific 
ways of setting X and Y parameters, but the default behavior should be 
one of reasonable performance, and not an immediate dispatch of 
xforms-value-changed for every keystroke.  Given that there are at least 
two delays to be customized, re-using the XForms @delay attribute for 
the vendor-specific extension seems like it should be avoided.

Discussion of Authoring Techniques:
Form authors need not dispatch a submission or perform an XSLT 
transformation for every xforms-value-changed event, either.
See http://www.w3.org/MarkUp/Forms/wiki/Submission_Request-Response_IDs 
for one consideration for throttling submission.
Do we need something more general here?

Leigh.