W3C home > Mailing lists > Public > www-forms@w3.org > September 2002

Re: XForms 1.0: My Opinions

From: John Keiser <jkeiser@netscape.com>
Date: Thu, 05 Sep 2002 17:16:09 -0700
Message-ID: <3D77F3C9.3020109@netscape.com>
To: tvraman@almaden.ibm.com
CC: www-forms@w3.org, Beth Epperson <beppe@netscape.com>, Daniel Glazman <glazman@netscape.com>

T. V. Raman wrote:

>John --
>When we specified the XForms processing model as we did in the
>specification we had two goals:
>0) Not to specify it  in terms  of a given algorithm or implementation
>1) at the same to ensure that the same form gave the same answer
>irrespective of how you implemented the processor.
>We achieved this by specifying the processing model declaratively i.e.
>in terms of pre and post conditions.
>We codified this pre-condition / post-condition specification in terms
>of events and event handlers.
This is where I disagree.  Have pre and post conditions.  Specify how 
things are declaratively going to work.  But don't make events unless 
someone needs to catch them.

>Now, from the scripting context  --especially in thinking of it in a
>runtime like Mozilla --you may well be right that there may be more
>granularity in the events as specified than you might perhaps need in
>scripting inside Mozilla--
>However, this granularity might also be key to implementing a
>distributed XForms processor where not all stages of processing live
>on the same point of the network.>>>>> "John" == 
Could you give an example of what you mean?  As long as you control both 
parts of this distributed XForms processor, you can handle both sides of 
the event.  If you don't, I would very much like to know what your 
vision is for this.

>In summary,  the events  such  as model-initialize and friends are
>there to specify the processing model declaratively.
This is one of the things I think we should avoid--unnecessary physical 
constraint of the implementation (the events do this).  An XForms 
implementation should work "as if the following algorithm were 
implemented"--but it should be kept a black box wherever possible so 
that the implementation can make optimizations that do not change the 

As an example, the form submission algorithm in the HTML spec is 
suboptimal, containing several major steps, some of which can be 
combined without affecting the output of the algorithm, which speeds 
submission up.  If the HTML spec had specified that events were fired in 
between each stage, browsers would have no choice but to follow the 
suboptimal algorithm (and to no effect, since the events are useless for 
anyone to catch).  But since it did not, I was able to combine steps and 
do things more efficiently.

We should provide for the future in this way as well.  Putting events 
between each step is like saying "the implementation MUST be coded in 
this specific way, with no deviation, even if the results are the same."

>With respect to DOM3 events we clearly couldn't depend on something
>that wasn't out there yet  as a W3C final CR --which is why we chose
>to create a set of abstract event types in the XForms namespace.
IMO, the event names are just names :)  If we choose names that are the 
same for the same function, who will blame us?  Also, we already do some 
DOM* events in the spec.

>As with XPath 2.0, we will probably use DOM 3.0 in XForms 2.0 --wel,
>that is once we wind up 1.0.
The thing is, in a web browser at least, you just don't get by without a 
DOM in forms.  More than anywhere else, this is where JS is going to be 
used in a browser.

Received on Thursday, 5 September 2002 20:16:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:07 UTC