incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <sandro.boe...@gmx.de>
Subject Re: JCR-Mapping VOTE : All commiters has to vote - Thanks
Date Wed, 10 Aug 2005 20:57:42 GMT

>> 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

Mime
View raw message