Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 99644 invoked by uid 500); 3 Nov 2002 03:42:36 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 99627 invoked from network); 3 Nov 2002 03:42:34 -0000 Message-ID: <05a501c282eb$381411c0$0100a8c0@MAUCHI> From: "Ivelin Ivanov" To: "joern turner" , Cc: =?iso-8859-1?Q?Ulrich_Nicolas_Liss=E9?= References: <3DC1CD04.3080107@web.de> <002501c28158$24688550$0100a8c0@MAUCHI> <3DC45C2E.2070002@web.de> Subject: Re: XForms contribution? Date: Sat, 2 Nov 2002 21:43:48 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Joern, I don't remember why I left with the impression that Chiba relies on JavaScript. I am glad that it doesn't. It is also good that both projects use JXPath for referencing the data model (be it DOM, JavaBean or mixed). XMLForm has a built in validation concept, currently through Schematron, which is convenient for gradual validation (wizard type). Timing seems to be good. Since you are planning on a new architecture for Chiba 2, and the Cocoon community is always open for good ideas, we can definitely help each other out. As far as my attempts to work with Chiba people is concerned, below are some past emails from the Cocoon mailing list. I don't have copies from the Chiba list. This is of course irrelevant now. Let's try to see how can we work together this time around. http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg13653.html http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg12676.html http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg11174.html Regards, Ivelin ----- Original Message ----- From: "joern turner" To: "Ivelin Ivanov" Cc: "Ulrich Nicolas Liss�" Sent: Saturday, November 02, 2002 5:13 PM Subject: Re: XForms contribution? Hello Ivelin, first of all, thanks for the quick response and your interest in Chiba. But there are some statements in your mail that really astonished me: you stated that you tried to contact us, but such a mail never reached me or the mailinglist. I answer all requests and try to give anyone feedback to whatever questions about Chiba. And, of course, i would have been happy about such a request! No criticism here, just try to clear this up. Another statement of yours let me suspect that you eventually might have mixed up Chiba with some other framework/project?: Chiba does *not* rely on Javascript - in contrary, it lives in a pure server-side java web-application and does not rely on any client intelligence. But besides these misunderstandings i think that Cocoon (or better XMLForm) and Chiba have a lot in common: - Like XMLForm, Chiba is client-independent, although we currently only support plain-html (without javascript) it's 'only' a matter of writing XSLT stylesheets to transform for other clients. - Like XMLForm Chiba does not support events, but it supports Actions (as far as they make sense on serverside) - we also try to adhere syntactically to the spec and by now have updated to the last working draft - we also take the freedom to leave out features that still feel 'weak' namely Events and Dependency Graph evaluation. We try to build a processor that behaves as defined by the spec without necessarily taking the way the spec proposes. - we build on common Apache libs like Xerces, Xalan, JXPath, Commons The Schema2XForms generator is currently undergoing adaption to the latest spec and comes with a supporting Ant task which allows to use it in build scripts. I think it could be a very helpfull tool whenever you have some existing XML Schemas and need a way to edit associated data. It's developed under Chiba2 which is planned as a XForms processor generator framework. i've had no deep look at XMLForm up to now (have to change that quickly). That may excuse my wrong term 'databean' here. i just had the impression, that instance-data in XMLForm are normally JavaBeans that hold the actual data (therefore 'databean'). Chiba uses DOM for instance-data but we plan to abstract this part to support arbitrary datamodels. I'm really looking forward to discussing things further on Cocoon-dev and also would like to crosspost messages to our list if you don't mind. Joern Ivelin Ivanov wrote: > Hi Joern, > > It is funny that when we started writing XMLForm for Cocoon, > Chiba already existed. I tried to contact the Chiba group multiple times for > a possible cooperation, but apparently there wasn't much interest. > > You are correct that XMLForm is designed for client independence. It will > work just as well for PDAs, PCs and cell phones, because it has no heavy > requirements for the client. > In fact there already is a contribution for VoiceXML. > > If I understand correctly Chiba heavily relies on JavaScript to simulate > XForms events and actions. > > Cocoon XMLForm sacrifices XForms events and actions in favor of universal > applicability. > We simply try to comply with the XForms tagnames and model referencing, > without going too far into implementing XForms features which have yet to be > proven. > For example if you had XUL or XForms capable client you can easily translate > XMLForm documents into any of the two grammars. > > > XML Schema -> XForms is an interesting idea which has been discussed on the > Cocoon list. Nothing has materialized though. > > Since XMLForm is much simpler of a framework than Chiba, I would like to > hear your ideas of upgrading Cocoon to a better form handling framework. > > Oh, one more thing. I am not sure I understand the comment about the > DataBean approach. XMLForm supports JavaBeans, DOM and mixed data models. > > > And if you don't mind I will take this discussion to the cocoon-dev list. I > think others will be interested to participate. > > > Looking forward to your ideas. > > > Ivelin > > > > ----- Original Message ----- > From: "joern turner" > To: "Ivelin Ivanov" > Cc: "Ulrich Nicolas Liss�" > Sent: Thursday, October 31, 2002 6:38 PM > Subject: XForms contribution? > > > >>Hello Ivelin, >> >>i'm very new to Cocoon but follow the development for quite a while and >>after struggling for years with servers of all kinds i now feel to have >>found the right one. Cocoon is really cool and i plan my future with it ;) >> >>please excuse that i took the direct way - wasn't sure if this topic >>would be correctly addressed at the cocoon mailing-lists (which one?). >> From following the discussions on the list i realized that you're >>tightly involved with the XMLForm module in Cocoon, so i hope i bother >>the right one ;) >> >>i am the founder of the Chiba project >>(http://sourceforge.net/projects/chiba) which tries to implement a >>XForms conformant processor for today browsers (even scriptless ones). >>The intend is to provide a bean-like component which may be integrated >>into arbitrary web-applications and supports a wide range of clients. It >>uses a DOM/XSLT approach. Next release (0.7) is scheduled for November. >>In paralell we work on a Schema2XForms generator which takes XML Schema >>and generates complete XForms with sensible defaults for the UI. >> >>The idea to integrate Chiba into Cocoon is not new in our group and has >>already successfully been done with a former version. >> >>XMLForm seems to have a different (DataBean) approach, but nevertheless >>we would be happy to contribute our experience and code to the Cocoon >>project. if you're interested, please have a look at our project page >>and tell me what you think. Don't expect too much from the web-site but >>i will be happy to answer all your questions. >> >>Regards, >> >>Joern Turner >> >> >> >> >> >> >> >> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org