W3C home > Mailing lists > Public > public-forms@w3.org > September 2007

Re: Erratum that removed the sending of MIP related events on model-construct

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 4 Sep 2007 20:57:17 -0700
To: ebruchez@orbeon.com
Cc: public-forms <public-forms@w3.org>
Message-ID: <OFF375B19D.050EED3E-ON8825734D.0011A05E-8825734D.0015BDE5@ca.ibm.com>
Hi Erik (and Nick and Joern and all),

Yikes! A big error has been made here.

Erratum E29a (cited by Nick at the beginning of this thread) did *not* 
remove the sending of MIP related events on model-construct.  There has 
been absolutely *no* change to XForms; the MIP-related events have never 
been dispatched on initialization, nor on instance replacement.

All E29a said was that xforms-rebuild, recalculate and revalidate would 
happen as behaviors rather than events (so that they are not cancellable 
during model construction).

This has *nothing* to do with sending MIP related events on 
model-construct and in fact there are categorically *no* changes to XForms 
1.0.  There is even a note in XForms 1.0 first edition in 
xforms-revalidate clarifying that "xforms-valid and other MIP-related 
events are not dispatched during the xforms-revalidate that happens during 
model construction).

It is good to know that there are additional use cases where it would 
sometimes be useful to have them all the time.  However, XForms 1.1 is way 
past last call, and we will easily blow our charter schedule if we were to 
take on more scope now.  I am quite concerned about asking the W3C for 
more time on XForms 1.1 given that it has been three years in the making 
and that we are discussing an issue that has *always* been a part of 

To me, the point of XForms 1.2 and XForms 2.0 is to continue addressing 
new and emerging use cases as working group members begin to feel the 
motivation to address them.  It is particularly important to take this 
approach when the new use cases conflict with the pre-existing use cases 
that caused the earlier versions of the language to have certain 

In the particular case of MIP-related events, they are not dispatched on 
initialization because we did not want a poor user experience esp. in the 
case of xforms-valid and xforms-invalid if the form author actually 
attempts to capture the event and present information to the user, e.g. a 
message.  So, I think it is unfair to say that the spec mandates "broken" 
behavior.  It doesn't mandate behavior that supports the feature you want, 
which is a form-wide error round-up.  It does a perfectly good job of 
letting a form author present an ephemeral message when the node the 
control is bound to *becomes* invalid as the result of XForms processing 
*in the current session*.

As a discussion about XForms 1.2/2.0, the use case of an error round-up is 
interesting, but we really need to have a look at it in terms of markup to 
decide whether the *feature* should even be done via eventing.  It seems 
you need eventing and more context info AND the context info you described 
isn't enough in the case of repeat...  Maybe a more direct construct is 
needed, like some kind of action that can query the current user interface 
and generate the error list into a node.  Don't get me wrong; I get the 
use case and in fact we have people who are doing it right now with our 
own custom extensions.  But we do need to treat this like a feature 

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

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

Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
08/30/2007 12:18 PM
Please respond to

public-forms <public-forms@w3.org>

Re: Erratum that removed the sending of MIP related events on 

Joern & all,

It is right that, *as they are currently defined*, the MIP events are
close to being useless unless an implementor makes some enhancements
that are not mandated by the spec.

One big use case we have is what we call the error summary. I showed
an example at a previous f2f in Amsterdam. This consists in having a
part of the form that summarizes the errors that have happened on the
form, for example at the top of the screen, or wherever the form
author wants to place it.

An XForms implementation could decide to build-in such summaries, but
every form author wants something slightly different. By implementing
MIP events correctly, you give form authors the ability to track this
kind of changes in the UI and easily implement such functionality with
a little snippet of XForms + XHTML and a little corresponding model
(having a system of components in XForms would make this even easier).

So the answer to your first question is: at Orbeon, yes, we have a use
case which we think is very important, and we would like the XForms
spec to support correctly this use case.

The enhancements we have made in Orbeon Forms wrt MIP events so far

* Dispatching them upon initialization. Apparently, other
   implementations (formsPlayer?) do this as well.

* Adding context information to the event such as the control id,
   alert information, etc.

* Implementing dispatching of MIP events upon instance replacement
   (following the same strategy which Joern proposed, and which
   unfortunately is not a good one as we already covered in a separate

But this is not enough. I have already shown that MIP events and
xforms-value-changed are dispatched unreliably in this message:


I don't think I need to re-explain all this, but we at Orbeon don't
think that it is acceptable that the specification mandate such broken

I fully agree with Joern's idea that MIP events are not necessarily
used to update the UI: they are notification events. I say
"necessarily" because there is the possibility that an implementation
could use them to update the UI (but I haven't checked if this is
actually possible).

Your idea of using xforms:refresh upon xforms-ready won't work,
because the nodes' MIP markings are cleared during
initialization. Refresh will occur, but no MIP events will be
dispatched. An alternative is to perform a submission upon
xforms-ready, but I call this a hack.

Regarding the cost of dispatching these events, there is a very easy
solution for Chiba (I assume): you can do what we do in Orbeon Forms
and simply never dispatch a particular UI event if there is no event
listener registered for that UI event. And if there is no UI event
listener at all, then you can skip an even bigger part of the
process. This is a static analysis which can be performed during form

So we both agree that something should be done about UI events, but I
think it would be better to define them correctly rather than
supressing them.

Finally, it would be great to hear of other use cases from other form
authors or implementors.


Joern Turner wrote:
 > Nick and all,
 > before actually rolling back this change we should IMO take a closer
 > look at the MIP events. It popped up shortly in the discussion on last
 > telecon (don't remember who mentioned it) that the overall usefulness 
 > MIP events can be questioned.
 > So first question to me is:
 > are there people outside using the MIP events for form authoring? Are
 > there really use cases for them? Please excuse the dumb question but i
 > myself haven't found a single case in the past where i needed these
 > events as a form author.
 > If we can't find striking use cases for MIP events they should be
 > deprecated and removed from the Spec for the following reasons:
 > - reduction of complexity
 > - reduction of processing overhead. DOM Events are not really a cheap
 > thing to process with all their capturing, blubbing and stuff. Every
 > value change fires a whole bunch of these which easily leads to 
 > of events for reasonable complex forms
 > Same argument applies for the init phase. I remember not too long ago
 > during the telecon it was said that we don't need the initial MIP 
 > cause the whole UI is *created* in contrast to being refreshed after
 > state changes in the instance. Of course when a control is created it
 > already gets its initial and correct state. So i don't see a strict
 > reason for firing the MIP events on init from a model-consistency point
 > of view.
 > Further we shouldn't forget that it's not the MIPs causing the UI being
 > up-to-date - they are pure notification events. The UI state itself has
 > to be updated by the processor itself in an implementation-dependent 
 > as current wording says:
 > 4.3.7:
 > (...)
 > 5. The user interface reflects the state of the model, which means that
 > all form controls reflect to their corresponding bound instance 
 > This correctly says what a processor is expected to do not how to do it
 > and certainly not through the use of MIP events. These a solely 
 > for the form author.
 > And finally, if we're finding cases where the author wants the MIP
 > events right after init why not just use
 > <xf:action ev:event="xforms-ready">
 >   <xf:refresh/>
 > </xf:action>
 > Just an implementors opinion: from my point of view i don't like to 
 > the MIP events during or right after init phase. This definitely
 > generates all lot of event processing for potentially exotic use cases
 > and i prefer a better startup time for the majority of use cases.
 > Maybe i'm just missing the important use case but it should be an
 > important one to justify the overhead.
 > Regards,
 > Joern
 > Nick_Van_den_Bleeken@inventivegroup.com wrote:
 >> All,
 >> We were talking on the phone about '4.2 Initialization Events' and
 >> this is the erata I meant. It removed the dispatching of the events on
 >> xforms-model-construct:
 >> http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E29a
 >> Regards,
 >> Nick Van den Bleeken  -  Research & Development
 >> Inventive Designers
 >> Phone: +32 - 3 - 8210170
 >> Fax: +32 - 3 - 8210171
 >> Email: Nick_Van_den_Bleeken@inventivegroup.com
 >> --------------------------------------------------
 >> Inventive Designers' Email Disclaimer:
 >> http://www.inventivedesigners.com/email-disclaimer

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Wednesday, 5 September 2007 03:58:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:53 UTC