xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: CfP: Apache JAXB Implementation Project
Date Mon, 05 Aug 2002 21:36:28 GMT

On Monday, August 5, 2002, at 09:26 PM, Paul Libbrecht wrote:

> Hi,
> I don't know jaxb but... I have the impression that Ant does quite a lot 
> of it and... in a confortable way ! Building on top of this would leave 
> good room for the developers to change their classes (anyways, the 
> possible speed loss due to reflection is not avoidable).

(i'm not an expert so hopefully people will correct me when i go wrong...)

i had a quick look at the jaxb spec and it seemed (to me) to use the 
generative approach. take a schema, generate some value beans and then 
generate mapping code. the developer can then modify the beans as they 
wish. i suppose a useful analogy might be a generative data access mapping 
layers such as jakarta-turbine-torque: the difference being that the value 
beans are mapping to xml rather than to relational tables,

this kind of thing can quite easily be built on top of ant. torque uses 
velocity driven from a custom ant task (texen). (i believe that people 
have made similar systems work using xslt.)

there is a component in jakarta-commons called betwixt which takes the 
alternative reflective approach. it creates dynamic mappings at runtime 
using reflection. this approach works well with existing object models. 
jaxb should be better when you want to create an object model from scratch 
based on a known schema.

a reflective solution will probably be more java-centric, starting from an 
existing object model with the xml reflecting that model whereas a 
generative solution will start from known xml and create an object model 
based on it. quite possibly a solution falling in the middle is likely to 
enjoy the failings of both without the distinct advantages of either.

- robert

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message