[jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

Hello,

at the moment as a pragmatic way the JAXB RI is used to bind the xml 
schema to the according
Java beans. For me it was basically to save time for Java model changes 
after changing the XML
schema. As I agree with the licence issues and possible other issues I'm 
+1 for an other library.
This is why I would like to collect some arguments with you and provide 
this as a starting point:

JaxMe 2:
++ pro +
o It's a JAXB implementation. This means if JAXB is accepted by the 
market it has the
advantages every Java spec has (exchangability, maybe it finds their way 
to the J2SE,
tool support, ...).
o In my opinion XML binding in general seems to be very time saving, 
type safe and object
oriented (XML schema).
++ con ++
o It seems to be very young. I don't know how stable it is.

Digester:
++ pro ++
o Many users may already have this library as it is part of 
Apache commons
o Uses mapping rules.

++ neutral ++
o I'm not sure if it supports XML schema. Which would make it
less type safe and object oriented.


XMLBeans:
++ pro ++
o It is a XML binding library with schema support which I think
is a very important feature. This would also make the development
easier.
o We could make the xml library exchangable.
Quote: "Extensions - You can now add custom functionality to 
generated XMLBeans. You can pass to the Schema Compiler 1) an 
interface that defines the set of methods to implement and 2) 
a static handler that implements this functionality. The 
generated classes will implement the interface and, for each 
method, call out to the static handler."
I'm not sure if it is too much abstraction for the advantage of
making the xml library exchangable. But we could make the mapping
objects representing the xml tags (e.g. a SubItemMapping class)
implementing an interface. This way the SubItemMapping object
could be filled by Digester, the JAXB RI, XML Beans or whatever
can unmarshall a xml file into a given Java bean structure. It
would make sure that the persistence manager and the node type
registration do not rely on Digester, XML Beans, JaxMe or whatever
library we chose but only on an interface.

BeanUtils:
++ pro ++
o Many users may already have this library as it is part of 
Apache commons

++ neutral ++
o Quote: "Consuming XML-based configuration resources (such as 
Ant build scripts, web application deployment descriptors, 
Tomcat's |server.xml| file)." Sorry, I don't know more about
this feature of BeanUtils. 

From all I know at the moment I would tend to XMLBeans but I'm
looking forward to your pro's and con's.

Regards,

Sandro

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

Christophe Lombart wrote:

>>Hello Christophe,
>>
>>the general advantage I see is, that you can have a better error
>>handling in comparison to a DTD.
>>In my opinion: the earlier the user find an error in the XML file the
>>better is it. With the XML schema
>>you have more possibilities than with a DTD because it is a superset of
>>a DTD.
>>    
>>
>You mean Xml schema is a superset of a DTD - of course but I found the
>proposed tools (XmlBean, JAXB, ...) not very usefull in our case. They
>add some complexity.
>Did you see the number of generated classes you have ? 
>
>  
>
 From all  know XMLBeans uses one implementation class and one interface 
for each type.

>I will have something 5 classes with 2/5 attributes in each of them.
>I'm not sure it is quite complex to write by hand (with eclipse).
>
>  
>
I don't think it will be complex. It will just be some work.

>  
>
>>Beside obvious advantages (like XML schema uses the XML syntax) as a
>>concrete example we can
>>use some build in data types like QName, ID, IDREF directly with the
>>schema. Or for the JCR
>>date types we can use the double, date, long, boolean schema types.
>>A binding framework can do the conversions. Which means, once we defined
>>a double or any other
>>datatype in the schema we don't need to deal with parsing, validation or
>>conversion from string
>>to the according data type. The type will simply be available in the
>>Java bean.
>>    
>>
>
>See in my prototype, it is the same situation 
>
>  
>
>>o writing Java objects as nodes to the repository
>>o loading nodes from the repository into Java objects
>>o generating node types out of Java classes
>>o generating Java classes out of node types
>>o ...
>>    
>>
>I don't see why it is not possible in my case.
>  
>
Thank you for the information I just didn't know that digester can 
handle custom type structures and
Java types.

>Please, look at tools like OJB, Hibernate & Jackrabbit. Let me know
>why they are not using XMLSchema. They have the same problem.
>  
>
You don't really want me to search for your arguments why Hibernate use 
a DTD, do you? ;-)
I can tell that EJB 3.0 (I think Hibernate will be a EJB 3.0 
implementation) don't use a DTD
and only use an XML schema and JDO 2.0 will use XML schema in addition 
to a DTD. But
I like more concrete problems and solutions.
I will tell you a joke to explain, why I don't like those arguments. 
Please quote me on this,
in case I also use those arguments sometimes ;-) :

It was autumn, and the Indians on the remote reservation asked their new 
Chief if the
winter was going to be cold or mild. Since he was an Indian Chief in a 
modern society,
he had never been taught the old secrets, and when he looked at the sky, 
he couldn't
tell what the weather was going to be.
Nevertheless, to be on the safe side, he replied to his tribe that the 
winter was
indeed going to be cold and that the members of the village should 
collect wood to be
prepared.
But also being a practical leader, after several days he got an idea.He 
went to the
phone booth, called the National Weather Service and asked, "Is the 
coming winter
going to be cold?"
"It looks like this winter is going to be quite cold indeed," the 
meteorologist at
the weather service responded. So the Chief went back to his people and 
told them to
collect even more wood in order to be prepared.
One week later he called the National Weather Service again. "Is it 
going to be a
very cold winter?"
"Yes," the man at National Weather Service again replied, "it's going to 
be a very
cold winter."
The Chief again went back to his people and ordered them to collect 
every scrap of
wood they could find.
Two weeks later he called the National Weather Service again. "Are you 
absolutely
sure that the winter is going to be very cold?"
"Absolutely," the man replied. "It's going to be one of the coldest 
winters ever.
"How can you be so sure?" the Chief asked.
The weatherman replied, "The Indians are collecting wood like crazy."


I just don't want to be the Indian ;-).


>Look at my last commit and let me know what's is wrong in this prototype. 
>  
>
I will not start a "my prototype is better than yours" ;-). I could not 
yet completely check
advantages or disadvantages.
We should take care not to reinvent the wheel with our two prototypes.

>I think it done with a small amount of code and without generated classes : 
>* DescriptorReader : read the mapping File by 5 using a small amount
>of classes (see in org.apache.portals.graffito.jcr.mapper.model).
>* See the GenericConverter to see how the mapping is done.
>
>
>  
>
It's good to see Digester "in action" as an example. I will try to get 
more into that.

Best regards,

Sandro

Re: [jcr-mapping] persistence of the mapping model

[Christophe Lombart <ch...@gmail.com>]

> Hello Christophe,
> 
> the general advantage I see is, that you can have a better error
> handling in comparison to a DTD.
> In my opinion: the earlier the user find an error in the XML file the
> better is it. With the XML schema
> you have more possibilities than with a DTD because it is a superset of
> a DTD.
You mean Xml schema is a superset of a DTD - of course but I found the
proposed tools (XmlBean, JAXB, ...) not very usefull in our case. They
add some complexity.
Did you see the number of generated classes you have ? 

I will have something 5 classes with 2/5 attributes in each of them.
I'm not sure it is quite complex to write by hand (with eclipse).

> Beside obvious advantages (like XML schema uses the XML syntax) as a
> concrete example we can
> use some build in data types like QName, ID, IDREF directly with the
> schema. Or for the JCR
> date types we can use the double, date, long, boolean schema types.
> A binding framework can do the conversions. Which means, once we defined
> a double or any other
> datatype in the schema we don't need to deal with parsing, validation or
> conversion from string
> to the according data type. The type will simply be available in the
> Java bean.

See in my prototype, it is the same situation 

> o writing Java objects as nodes to the repository
> o loading nodes from the repository into Java objects
> o generating node types out of Java classes
> o generating Java classes out of node types
> o ...
I don't see why it is not possible in my case.
Please, look at tools like OJB, Hibernate & Jackrabbit. Let me know
why they are not using XMLSchema. They have the same problem.
Look at my last commit and let me know what's is wrong in this prototype. 

I think it done with a small amount of code and without generated classes : 
* DescriptorReader : read the mapping File by 5 using a small amount
of classes (see in org.apache.portals.graffito.jcr.mapper.model).
* See the GenericConverter to see how the mapping is done.

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

>
> The argument which is maybe most important for me:
> In my opinion it is more than a config file. I think it is some kind 
> of model (like the one in MVC)
> for the mapping between Java entities and JCR entities. Therefore I 
> would like to have an
> in memory Java bean representation of that model. This mapping model 
> can than be the basis for
> every conversion between the Java entities and the JCR entities e.g. 
> it can be used for:
> o writing Java objects as nodes to the repository
> o loading nodes from the repository into Java objects
> o generating node types out of Java classes
> o generating Java classes out of node types
> o ...
>
> A simple change in the XML schema file would change the model (the 
> generated Java beans)
> after regeneration and this changed model would be immediately 
> available for all components
> using this model.
>
I basically think, writing the classes from the scratch would lead me to 
the same structure of
the generated classes anyway.

Regards,

Sandro
<ci...@gmx.de>

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

>No - Let me resume why I'm agains tools like XmlBeans, JAXB, ... and
>XML schema :
>* Thoses tools are generating java classes and sometime it is
>difficult to change the class object structure. We will have a few
>number of java classes to read the config file. So write by hand
>thoses classes is not a big deal. Futhermore, using a pre-processing
>in order to just read a simple config file is a little bit heavy - no
>:-) ?
>* The mapping file should be very simple - I hope it will be otherwise
>the framework will not be used :-). So, a simple DTD is sufficiant.
>Xml schema becomes interesting for more complex grammar. See
>Jackrabbit, Hibernante, OJB, ... all these frameworks are using very
>simple DTD.
>* We need to read the mapping file and cache it in memory (in an
>object graph). So, Digester is (for me) one of the best tools to do
>it. Others framework become interesting when your update the xml file
>content.
>* See http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester.
>
>Give 2 days, I hope to commit a small example (before my upcoming vacations). 
>
>Christophe 
>
>  
>
Hello Christophe,

the general advantage I see is, that you can have a better error 
handling in comparison to a DTD.
In my opinion: the earlier the user find an error in the XML file the 
better is it. With the XML schema
you have more possibilities than with a DTD because it is a superset of 
a DTD.
Beside obvious advantages (like XML schema uses the XML syntax) as a 
concrete example we can
use some build in data types like QName, ID, IDREF directly with the 
schema. Or for the JCR
date types we can use the double, date, long, boolean schema types.
A binding framework can do the conversions. Which means, once we defined 
a double or any other
datatype in the schema we don't need to deal with parsing, validation or 
conversion from string
to the according data type. The type will simply be available in the 
Java bean.
I think a XML schema is not much more complex than a DTD when they cover 
the same
requirements. I'm not sure if it is representative but please have a 
look at this page for
a simple example:
http://www.w3schools.com/schema/schema_howto.asp

The argument which is maybe most important for me:
In my opinion it is more than a config file. I think it is some kind of 
model (like the one in MVC)
for the mapping between Java entities and JCR entities. Therefore I 
would like to have an
in memory Java bean representation of that model. This mapping model can 
than be the basis for
every conversion between the Java entities and the JCR entities e.g. it 
can be used for:
o writing Java objects as nodes to the repository
o loading nodes from the repository into Java objects
o generating node types out of Java classes
o generating Java classes out of node types
o ...

A simple change in the XML schema file would change the model (the 
generated Java beans)
after regeneration and this changed model would be immediately available 
for all components
using this model.


 >* See http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester.
I checked the described drawbacks there. Here are my comments:
"you need an xml schema that defines your input xml"
As I already pointed out, I see this as a good thing.

"you need to run a "pre-processor" to generate code"
I afraid I don't get the point here as I think you would need to write 
the code by yourself
in the other case.

"you may or may not have much choice about the names of the generated 
classes, or the
way inter-object relationships are represented."
I would like to control the names and the structure with the XML schema.

"the generated classes don't contain any "business logic", just plain 
getter and setter methods
for the data"
I my case it's a model which must not have any business logic.

"if you modify any of the generated classes, then later need to 
regenerate them because the
schema has changed, your changes are wiped out."
It should be a simple model filled by a XML file and like I said before, 
I worried about
the extensability of JAXB 1.0. But the XMLBeans feature list says:
"Extensions - You can now add custom functionality to generated 
XMLBeans. You can
pass to the Schema Compiler 1) an interface that defines the set of 
methods to implement
and 2) a static handler that implements this functionality. The 
generated classes will
implement the and, for each method, call out to the static handler."
At the moment I would say we don't need injected functionality, but who 
knows... ;-).

Kind regards,

Sandro

Re: [jcr-mapping] persistence of the mapping model

[Christophe Lombart <ch...@gmail.com>]

2005/8/2, Sandro Böhme <sa...@gmx.de>:
> Christophe Lombart wrote:
> 
> >+0 because I think tools like Digester is so simple to use in such case.
> >Please, make a small document on the xml schema to use for the mapping.
> >
> >Christophe.
> >
> >
> Do I understand it right, that you vote +0 for XML-schema and Digester
> is simple to use with
> XML-schema?
> What should the document contain?
> 

No - Let me resume why I'm agains tools like XmlBeans, JAXB, ... and
XML schema :
* Thoses tools are generating java classes and sometime it is
difficult to change the class object structure. We will have a few
number of java classes to read the config file. So write by hand
thoses classes is not a big deal. Futhermore, using a pre-processing
in order to just read a simple config file is a little bit heavy - no
:-) ?
* The mapping file should be very simple - I hope it will be otherwise
the framework will not be used :-). So, a simple DTD is sufficiant.
Xml schema becomes interesting for more complex grammar. See
Jackrabbit, Hibernante, OJB, ... all these frameworks are using very
simple DTD.
* We need to read the mapping file and cache it in memory (in an
object graph). So, Digester is (for me) one of the best tools to do
it. Others framework become interesting when your update the xml file
content.
* See http://wiki.apache.org/jakarta-commons/Digester/WhyUseDigester.

Give 2 days, I hope to commit a small example (before my upcoming vacations). 

Christophe 





> Sandro
> 
> >
> >2005/8/2, Oliver Kiessler <ol...@gmail.com>:
> >
> >
> >>>Regarding XML-schema:
> >>>I think we will need a definition for the XML file somehow or other. Be
> >>>it in writing form, a DTD or a
> >>>XML-schema. The schema is the more advanced than DTD. The user will have
> >>>a valid XML file as
> >>>early as possible. I think the writing form of explaining the definition
> >>>is much more work if it has the same
> >>>quality as the schema.
> >>>
> >>>I think we need a XML-schema ballot in order to be able to close the
> >>>ballot about the persistence
> >>>technology of the mapping model.
> >>>
> >>>++ Please vote if you think we need a XML schema for the XML file of the
> >>>mapping model. ++
> >>>
> >>>
> >>ok. I think you have a point here, therefore I vote +1.
> >>
> >>oliver
> >>
> >>
> >>
> >
> >
> >
> >
> 
>

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

Christophe Lombart wrote:

>+0 because I think tools like Digester is so simple to use in such case.
>Please, make a small document on the xml schema to use for the mapping.
>
>Christophe.
>  
>
Do I understand it right, that you vote +0 for XML-schema and Digester 
is simple to use with
XML-schema?
What should the document contain?

Sandro

>
>2005/8/2, Oliver Kiessler <ol...@gmail.com>:
>  
>
>>>Regarding XML-schema:
>>>I think we will need a definition for the XML file somehow or other. Be
>>>it in writing form, a DTD or a
>>>XML-schema. The schema is the more advanced than DTD. The user will have
>>>a valid XML file as
>>>early as possible. I think the writing form of explaining the definition
>>>is much more work if it has the same
>>>quality as the schema.
>>>
>>>I think we need a XML-schema ballot in order to be able to close the
>>>ballot about the persistence
>>>technology of the mapping model.
>>>
>>>++ Please vote if you think we need a XML schema for the XML file of the
>>>mapping model. ++
>>>      
>>>
>>ok. I think you have a point here, therefore I vote +1.
>>
>>oliver
>>
>>    
>>
>
>
>  
>

Re: [jcr-mapping] persistence of the mapping model

[Christophe Lombart <ch...@gmail.com>]

+0 because I think tools like Digester is so simple to use in such case.
Please, make a small document on the xml schema to use for the mapping.

Christophe.


2005/8/2, Oliver Kiessler <ol...@gmail.com>:
> > Regarding XML-schema:
> > I think we will need a definition for the XML file somehow or other. Be
> > it in writing form, a DTD or a
> > XML-schema. The schema is the more advanced than DTD. The user will have
> > a valid XML file as
> > early as possible. I think the writing form of explaining the definition
> > is much more work if it has the same
> > quality as the schema.
> >
> > I think we need a XML-schema ballot in order to be able to close the
> > ballot about the persistence
> > technology of the mapping model.
> >
> > ++ Please vote if you think we need a XML schema for the XML file of the
> > mapping model. ++
> 
> ok. I think you have a point here, therefore I vote +1.
> 
> oliver
>

Re: [jcr-mapping] persistence of the mapping model

[Oliver Kiessler <ol...@gmail.com>]

> Regarding XML-schema:
> I think we will need a definition for the XML file somehow or other. Be
> it in writing form, a DTD or a
> XML-schema. The schema is the more advanced than DTD. The user will have
> a valid XML file as
> early as possible. I think the writing form of explaining the definition
> is much more work if it has the same
> quality as the schema.
> 
> I think we need a XML-schema ballot in order to be able to close the
> ballot about the persistence
> technology of the mapping model.
> 
> ++ Please vote if you think we need a XML schema for the XML file of the
> mapping model. ++

ok. I think you have a point here, therefore I vote +1.

oliver

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

Sandro Böhme wrote:

> Christophe Lombart wrote:
>
>>> +1 for Digester if you don't need XML Schema support, +1 for XMLBeans
>>> if we need it
>>>
>>>   
>>
>> +1
>>
>>  
>>
> Do you vote +1 for both, Digester and XML Beans also dependent on the 
> Schema support?
>
> What do you both think about the exchangability of the library?
>
>>> I think we don't necessarily need XML Schema support because I believe
>>> the mapping config xml file will not change very often (maybe during
>>> development...)
>>
>
>> Same opinion 
>
> I'm not sure if the mapping specification is really stable or if it will
> get stable quite fast.
>
> Pro XML-schema:
> o Easier to keep the allowed XML structure in sync with the mapping 
> model.
> o The user can validate their XML file with the XML schema and we 
> don't need
> very much error handling in the application. I assume that XML schema 
> can validate more than Digester can because the schema knows the 
> types, structure and cardinality 
> <se?lp=ende&p=/Mn4k.&search=cardinality>. But I don't know very much 
> about digester, so I could be wrong.
>
> Regards,
>
> Sandro
>
>
Regarding XML-schema:
I think we will need a definition for the XML file somehow or other. Be 
it in writing form, a DTD or a
XML-schema. The schema is the more advanced than DTD. The user will have 
a valid XML file as
early as possible. I think the writing form of explaining the definition 
is much more work if it has the same
quality as the schema.

I think we need a XML-schema ballot in order to be able to close the 
ballot about the persistence
technology of the mapping model.

++ Please vote if you think we need a XML schema for the XML file of the 
mapping model. ++

Because of the above arguments I vote with +1 for XML schema.

Cheers,

Sandro

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

Christophe Lombart wrote:

>+1 only for Digester. I think XML Schema is not necessary for a confi file. 
>it should quite stable. I see only new elements used new features. 
>
>Christophe
>  
>
 >I think XML Schema is not necessary for a confi file.
Sorry I don't understand what is special for a xml file which acts as a 
config file.

Re: [jcr-mapping] persistence of the mapping model

[Christophe Lombart <ch...@gmail.com>]

+1 only for Digester. I think XML Schema is not necessary for a confi file. 
it should quite stable. I see only new elements used new features. 

Christophe


2005/8/1, Sandro Böhme <sa...@gmx.de>:
> Christophe Lombart wrote:
> 
> >>+1 for Digester if you don't need XML Schema support, +1 for XMLBeans
> >>if we need it
> >>
> >>
> >>
> >+1
> >
> >
> >
> Do you vote +1 for both, Digester and XML Beans also dependent on the
> Schema support?
> 
> What do you both think about the exchangability of the library?
> 
> >>I think we don't necessarily need XML Schema support because I believe
> >> the mapping config xml file will not change very often (maybe during
> >> development...)
> 
> >Same opinion
> I'm not sure if the mapping specification is really stable or if it will
> get stable quite fast.
> 
> Pro XML-schema:
> o Easier to keep the allowed XML structure in sync with the mapping model.
> o The user can validate their XML file with the XML schema and we don't need
> very much error handling in the application. I assume that XML schema can
> validate more than Digester can because the schema knows the types, structure
> and cardinality <se?lp=ende&p=/Mn4k.&search=cardinality>. But I don't know very much about digester, so I could be
> wrong.
> 
> Regards,
> 
> Sandro
> 
>

Re: [jcr-mapping] persistence of the mapping model

[Sandro Böhme <sa...@gmx.de>]

Christophe Lombart wrote:

>>+1 for Digester if you don't need XML Schema support, +1 for XMLBeans
>>if we need it
>>
>>    
>>
>+1
>
>  
>
Do you vote +1 for both, Digester and XML Beans also dependent on the 
Schema support?

What do you both think about the exchangability of the library?

>>I think we don't necessarily need XML Schema support because I believe
>> the mapping config xml file will not change very often (maybe during
>> development...)

>Same opinion 
I'm not sure if the mapping specification is really stable or if it will
get stable quite fast.

Pro XML-schema:
o Easier to keep the allowed XML structure in sync with the mapping model.
o The user can validate their XML file with the XML schema and we don't need
very much error handling in the application. I assume that XML schema can 
validate more than Digester can because the schema knows the types, structure 
and cardinality <se?lp=ende&p=/Mn4k.&search=cardinality>. But I don't know very much about digester, so I could be 
wrong.

Regards,

Sandro

Re: [jcr-mapping] persistence of the mapping model

[Christophe Lombart <ch...@gmail.com>]

> +1 for Digester if you don't need XML Schema support, +1 for XMLBeans
> if we need it
> 
+1

> I think we don't necessarily need XML Schema support because I believe
> the mapping config xml file will not change very often (maybe during
> development...)
> 
Same opinion 

> +1 for BeanUtils for java bean support/reflection etc.
+1

2005/7/31, Oliver Kiessler <ol...@gmail.com>:
> > From all I know at the moment I would tend to XMLBeans but I'm
> > looking forward to your pro's and con's.
> 
> +1 for Digester if you don't need XML Schema support, +1 for XMLBeans
> if we need it
> 
> I think we don't necessarily need XML Schema support because I believe
> the mapping config xml file will not change very often (maybe during
> development...)
> 
> +1 for BeanUtils for java bean support/reflection etc.
> 
> regards,
> oliver
>