> >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...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|