RE: incremental delay considered harmful

Alain,

To me it still feels that the delay should be something the XForms processor should 'calculate' himself ideally without any specific attributes on the control because:

·         The form author shouldn't have to worry about what the best value for the delay is

·         May depend on the device on which the form is ran

·         May depend the XForms processor (pure client based or client/server based)

·         May even vary on load and or version of the external service that is called

I'm not saying that an XForms implementation couldn't have configuration parameters (or even a processor specific attribute on the control or form if really desired) that can be used to 'calculate' the optimal value for delays between xforms-value-change events.

The implementation is more suited for doing the calculation because it could for example take into account the time needed to process previous xforms-value-change events, and or don't dispatch a new xforms-value-change event until all processing of the previous event is done (also asynchronous submissions -> this should already the case I think because 'Under no circumstances can more than a single concurrent submit process be under way for a particular XForms submission').

Kind regards,
Nick Van den Bleeken
R&D Manager
Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com<http://www.inventivedesigners.com/>
[Description: Linked-In]<http://www.linkedin.com/company/inventive-designers>[Description: twitter]<http://www.twitter.com/inventivedes>[Description: newsletter]<http://www.inventivedesigners.com/newsletter>
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of COUTHURES Alain
Sent: maandag 28 maart 2011 23:05
To: Leigh L. Klotz, Jr.
Cc: public-forms@w3.org; www-forms@w3.org
Subject: 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.









--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer