From graffito-dev-return-408-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Wed Aug 10 20:54:20 2005 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 58104 invoked from network); 10 Aug 2005 20:54:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Aug 2005 20:54:20 -0000 Received: (qmail 72594 invoked by uid 500); 10 Aug 2005 20:54:19 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 72581 invoked by uid 99); 10 Aug 2005 20:54:19 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Aug 2005 13:54:19 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of sandro.boehme@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 10 Aug 2005 13:54:41 -0700 Received: (qmail invoked by alias); 10 Aug 2005 20:54:17 -0000 Received: from p54A3F564.dip.t-dialin.net (EHLO [192.168.2.2]) [84.163.245.100] by mail.gmx.net (mp033) with SMTP; 10 Aug 2005 22:54:17 +0200 X-Authenticated: #1646957 Message-ID: <42FA6A46.40009@gmx.de> Date: Wed, 10 Aug 2005 22:57:42 +0200 From: =?ISO-8859-1?Q?Sandro_B=F6hme?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: graffito-dev@incubator.apache.org Subject: Re: JCR-Mapping VOTE : All commiters has to vote - Thanks References: <3b728ee905080416386f0419de@mail.gmail.com> <42F4BE5F.3060204@gmx.de> In-Reply-To: <42F4BE5F.3060204@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N >> Proposal 1 (Christophe) >> ---------------------------------- >> * I'm doing a prototype - see in the head (subproject jcr-mapping). >> The starting point is the unit test called : JcrSessionTest >> >> This code do the following steps : * Read the mapping file with >> Digester and load it in memory (object >> graph) - See the class DescriptorReader in the prototype. The >> prototype is not complete. >> * A simple DTD is sufficiant for this kind of operation. * Use >> BeanUtil to convert in both direction pojo <-> jcr node (see in >> the prototype the class : GenericConverter). >> >> + : simple code and light tools >> - : classes used to read the mapping file have to be write by hand. >> Thanks to the limited number of classes, it should not be a problem. >> >> Proposal 2 (Sandro) ---------------------------- >> * Sandro made a prototype - see in Jira ( GRFT-34) : >> http://issues.apache.org/jira/browse/GRFT-34 >> * Use XmlSchema and tools like JAXB or XmlSchema to manage the xml >> mapping file. >> >> >> > Arguments for XML schema and XMLBeans: > + : The XML schema and the mapping class model are redundant > information in my opinion. So for me > it seems to be straightforward to generate the mapping model classes > out of the XML > schema (e.g. with XMLBeans). You will need to change the mapping class > model if the > specification of the XML file changes and vice versa. > > > + : Isn't it also possible for Digester to use XML Schema? I think so, > but I guess I'm not the > Digester expert here. > + : The XML schema and the classes should not get out of sync. > + : With the type support of XML schema I think we could reproduce > many of the JCR > entities from items down to concrete JCR property types and of course > Java bean > structures. This makes it possible to have very much semantics of the > XML file already > validated by the XML schema. > - : A Class and an Interface is generated for each type. > - : As XML Beans is a generator is should be sufficient to have the > license in the xsd file. > But to be sure I would like to have it in the generated classes. This > would need some > extra effort. Of course I'm in charge to care about it. > - : Extensions to the generated classes should not be needed very > often. In case it is > needed, the classes are extended in a not quite familiar way. > >> Why I'm not agree with Sandro : >> ---------------------------------------------- I don't see the >> advantage to use the XML schema in THIS case. The xml >> mapping file has to be quite simple to read and generate classes is >> overkill in this situation. We can do exactly the same think with very >> light tools... but maybe I'm wrong ! > Hello Christophe, if you are back from vacation and read my arguments and you are +1 for Digester anyway, I'm +0 for Digester for not slowing down the project. Basically because it is only a matter of work to keep the XML file specification in sync with the mapping class model and it will not have any impact to the user. But at the moment I don't see any arguments contra XML schema. Regards, Sandro