Re: incremental delay considered harmful

I understand it is surely a bad idea for a server-side implementation to 
exchange data between the client and the server at every keystroke.

Nevertheless, this is quite natural for a client-side implementation of 
XForms, such as XSLTForms, to dispatch an xforms-value-changed event at 
every keystroke. An auto-adaptative algorithm appears to be much more 
complex to elaborate, considering also that, for the same control, the 
best X and Y values might be different between browsers and client 
computers.

Clearly, in the same form, some actions such as client-side XSLT 
transformations or cross-domain submissions might require more time 
while others will be almost immediate. It's the same when refresh 
requires a lot of changes in the form and I can't see in the XY proposed 
mechanism how to manage this at control level. Client-side performance 
is not constant whereas, I suppose, server-side performance is mostly 
due to exchanges when having a good server ;-)

So, for me, it is important to let the developer of any kind of 
implementation being able to tune himself the dynamic behavior of the 
controls of his forms.

I don't think either that it would always be good to have to add a 
trigger instead of using the incremental mode.

So, I can understand that a delay attribute might disturb the current 
Orbeon mechanism but, if not in the XForms specifications, a delay 
attribute should still be implemented in XSLTForms for practical 
reasons. I'm afraid that compatibility between implementations is not 
effective today anyway, because of so many extensions provided by them 
(and, I'm sure, always for excellent reasons). If we want compatibility 
(required, for example, for external authoring tools), we all need to 
converge and it will cost efforts for all...

Would it help to say that it has to be interpreted as a minimal delay?

Alain Couthures
XSLTForms Project Leader

Le 23/03/2011 18:32, Leigh L. Klotz, Jr. a écrit :
> [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.
>
>
>
>
>
>
>
>