W3C home > Mailing lists > Public > public-forms@w3.org > March 2011

Re: incremental delay considered harmful

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 30 Mar 2011 09:54:54 -0700
To: Joern Turner <joern.turner@googlemail.com>
Cc: "Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>, public-forms@w3.org, www-forms@w3.org
Message-ID: <OF99BC1DE9.D369799F-ON88257863.005B2DA3-88257863.005CEFB3@ca.ibm.com>
Minutes today indicated that Leigh now has an action to respond to the 
thread on this, but not what was decided regarding that response.

Seeing that there is a desire to possibly add a delay attriute to "control 
how frequently" xforms-value-changed events are dispatched, I wonder 
whether everyone who wants this is on the same page about which direction 
the control is in?

Is it meant to be a maximum amount of time that will be waited before 
another xforms-value-changed is dispatched, or is it meant to be a minimum 
amount of time that will be waited before the next xforms-value-changed is 

In both cases, the logic around not dispatching another if there is still 
a change request on the event queue still makes sense.

Somehow it feels wrong to set this kind of thing on a per-control basis, 
or at least it seems wrong to only have that mechanism.  At least as an 
option, wouldn't form authors benefit from being able to set this in one 
place for all incremental controls for the sake of UX consistency? 
Otherwise, users will tend to get annoyed when various controls don't 
behave in the same way because the author didn't have the stamina to make 
the setting everywhere.

Finally, whether or not "incremental delay considered harmful" might it be 
the case that "incremental delay considered low priority"?  If it's not a 
high priority, then perhaps we could consider use of RFC2119 words other 
than MUST, i.e. maybe its an optional feature?

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: 

From:   Joern Turner <joern.turner@googlemail.com>
To:     "Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>
Cc:     public-forms@w3.org, www-forms@w3.org
Date:   03/30/2011 01:57 AM
Subject:        Re: incremental delay considered harmful
Sent by:        www-forms-request@w3.org


On Wed, Mar 23, 2011 at 6:32 PM, Leigh L. Klotz, Jr.
<Leigh.Klotz@xerox.com> wrote:
> [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 
> dispatch xforms-value-changed events.
Right - betterFORM also has a such a delay attribute.

> We've discussed a proposal to add this to XForms 1.2 three times, and 
> 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 
> answered by XForms 1.1 facilities.  If you believe that the use cases 
> answered, or if there are other significant use cases, please let us 
> If you believe the implementation techniques described below are 
> or too difficult, please let us know.  Otherwise we'll assume that there 
> no need to add @delay to form controls, and that implementations will
> eventually drop the extension in favor of the techniques similar to 
> 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 
> one of reasonable performance, and should not result in an immediate
> dispatch of xforms-value-changed for every keystroke.
Agree - the default behavior should work for the user.

Though i do not see a special reason why it is considered harmful to
dispatch xforms-value-changed for every keystroke. As XForms is
device- and platform-independent it might very well work for an
implementation to do so as the device maybe not even use a network
connection - this at least is the only reason i can see - that there
is a worry that firing events too often causes a lot of requests over
the network. So, if i'm not overseeing something it is mainly a matter
of performance of the implementation. I'm not sure if i'd like to see
(in lack of a better term) 'performance  policies' in a spec.

Of course it's a main interest of an implementer to provide a solution
with reasonable performance for the user - otherwise it's not very
likely that many people will use this implementation. How this is
achieved is a complete different matter and implementers should not be
constrained in their approach IMO. E.g. if an implementation uses a
socket connection (lets say CometD) then it can perform very well and
does not necessarily cause a lot of requests (as just one connection
is used) or perform badly due to the amount of events. If so, an
implementer will change this in his/her own interest.

So, agree that the default should work but i still think that there
are situations where you need this kind of fine-tuning as an author -
one obvious indicator for this fact is that at least 2 (3?) XForms
have added this as a feature. For the sake of interoperability it may
make sense to allow an attribute like @delay however it will be named
(that's just syntax).

> Use case: server-side completion
> input/@incremental='true' is used with an xforms-value-changed event 
> which dispatches send to an asynchronous submission.  Submission 
> are used to update the itemset of an accompanying xf:select1.  If the 
> 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 
> 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 
> dispatch of xforms-value-changed events.
This kind of confuses me - these use cases seem to argue for a @delay 

> XForms 1.1:
> XForms 1.1 does not require that xforms-value-changed be dispatched on 
> keystroke.  (In fact there might not even be keystrokes, depending on 
> user interface medium.)
Fully agree - it does not need to dispatch on every keystroke but why
shouldn't it be allowed to do so if that's appropriate for the device
or platform?

And of course it does not need to be a keystroke - it also may be a
person speaking a work letter by letter in a phone app. But
implementations are typically more or less constrained or tied to
certain platforms and have to use the mechanisms of the platform - in
one case these are keystrokes in another maybe 'speech events'.
> Discussion of Implementation Techniques:
> Erik Bruchez points out that Orbeon offers a simple heurstic-based 
> 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 
> If the user stops typing for more than Y milliseconds, dispatch the 
> 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 
> of reasonable performance, and not an immediate dispatch of
> xforms-value-changed for every keystroke.  Given that there are at least 
> delays to be customized, re-using the XForms @delay attribute for the
> vendor-specific extension seems like it should be avoided.
I have to confess that i'm kind of confused where the WG is heading
here - on the one hand the use of @delay seem to be considered harmful
but XForms processors might still choose to do so ?

Again - i fully understand and agree that the default behavior for
incremental should give the user a reasonable performance. The whole
idea of @delay is one of an optimization for situations that are
uncommon (at least we see it like that and i'm quite sure that no
vendor really enforces that attribute or otherwise perform badly).

The fact that several processors have added this feature is IMO an
indicator that such a facility is needed in some rare situations. For
the sake of interoperability it would be good if the facility could be
expressed in standardized markup.


> 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 
> one consideration for throttling submission.
> Do we need something more general here?
> Leigh.
Received on Wednesday, 30 March 2011 16:55:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:04 UTC