> >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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
