[whatwg] [wf2] form submission algorithm questions

[Benjamin West]

At
http://bewest.wordpress.com/2007/04/10/webforms-2-submissionvalidation-model/
, I discuss the submission/validation algorithm specified in
http://www.whatwg.org/specs/web-forms/current-work/#form-submission .
Applications won't be able to trust any incoming input, without some mechanism
that ensures that the validation steps have been followed.  Even if such a
mechanism existed, I suspect (but lack evidence) that most applications
require additional validation beyond type and format.  I also am a bit
confused about the usability issues surrounding exposing errors in the input
type and format to end users.

This creates a maintenance problem:  two implementations performing some set
of similar capabilities.  When I do validation in my web applications, I
implement all the validation on the server, and expose the validation through
some protocol.  Many times, I use some combination of XHR + submission + json
formatted responses.  This ensures one implementation that allows the
application to communicate its expectations of valid input beyond format and
type.

Would it be feasible to modify the algorithm to specify some kind of protocol
to iteratively validate content until it's correct? The type/format validation
is ok as a baseline for communication an application's expectations of input.


I suggest something like:

1.) Step One:     a new event "onvalidate" is dispatched
2.) Step Two:     Identify form controls.
3.) Step Three:   build form data set.
4.) Step Four:    encode data set.
5.) Step Five:    submit data set to validation URI.
6.) Step Six:     dispatch recieved
7.) Step Seven:   process validation results
  if response indicates validity->
   Submit using steps 2 - 8 of original algorithm.
  if response indicates invalid input->
   rinse and repeat

There's a lot of stuff missing from this proposal, I suppose, and I'm not even
sure how feasible it is to introduce events like onvalidate (or some analog).

The protocol for the messages exchanged and the format of the response would
need to be specified.  The data set submitted for validation should probably
include either the type information specified in the markup, or an identifier
unique within the application.  I suspect some profile technology, perhaps
combined with XBL, could provide mechanisms for facilitating useful error
handling interfaces for the end user.  I'm also unfamiliar with any security
concerns.


-Ben West