cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: HEADS UP - cocoon form handling (long!!)
Date Fri, 12 Apr 2002 07:50:41 GMT
> >Torsten Curdt wrote:
> >I second Torten's comments.  XForms cannot cleanly be implemented on the
> >server side.  There are things like XForm events that cannot work
> >correctly.  We *need* a client plugin to process XForms based work which
> >is sad.
> >I have been back and forth with the XForms expert group, and noone has
> >been able to convince the W3C workgroup that XForms needs to be friendly
> >to the server as well.  On the contrary, they have been resolute on
> >making it a client standard--while trying to pay lip service to the
> >server folks.  There are several people who have tried to get them to
> >see the light, and have been meet with statements ranging from "you
> >don't get it" to them completely missing the point of the argument--or
> >completely ignoring it.
> >It is not a pleasant standard to work with, and I am saddened by that.
> I cannot dispute this, having never tried to write an XForms processor...
> but when I say "XForms" I really mean an "XForms like" abstract form
> description language.  The closer to XForms syntax, the better, because
> 1) more people might find it familiar and 2) the syntax seems to be
> able to describe a wide variety of forms.  So what's the harm of
> adopting an already well thought out tag structure?

As long as we don't restrict ourself by that there is nothing wrong. But
there are things in the spec that *I* think are not so intuitive at all if
we choose to adopt them as they are... (e.g. the "submitInfo") if we also
want elegance we should drop those...

To unsubscribe, e-mail:
For additional commands, email:

View raw message