Berin Loritsch
<bloritsch@apache To: [EMAIL PROTECTED]
.org> cc:
Subject: Re: HEADS UP - cocoon form
handling
04/11/02 12:37 PM (long!!)
Please respond to
cocoon-dev
>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?
I don't pretend to understand XForms Processor implementation issues, just
the advantages of using a standard abstract form description markup, which
the XForms tag set provides. If I have implied otherwise, mea culpa.
Cheers,
--Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
