[Axis2] Better Java-XML mapping

[Dennis Sosnoski <dm...@sosnoski.com>]

I've been having some off-list email exchanges on the issues of better 
tools for going between Java and XML. This is relevant to both 
start-from-Java approaches to web services, and handling schema 
versioning. Since these issues are important for Axis2 I'll get this 
thread going here, assuming nobody objects to us using the Axis2 list 
for this purpose. I'm copying the jibx-devs list on my own emails on 
this topic just so that people monitoring that list are also aware of 
the discussion.

While we have a number of tools for generating Java object models to 
(more or less) match a schema, most of these tools either cannot work 
with pre-existing Java classes or can only work with existing classes 
using their own built-in correspondences. This limitation makes it very 
difficult for users to take a start-from-Java approach to developing web 
services, since the users then have little or no control over the 
schemas used by the web service (as seen with the JAX-RPC 1.0-style 
doc/lit mapping). It also makes it very difficult for users to work with 
evolving schemas, since their data model will need to be regenerated 
every time the schema changes. Because of this, users often end up 
writing a translation layer into their applications to take the data 
from the schema-centric model and convert it into structures actually 
used by their main application code.

There are some libraries which provide more flexible conversions between 
Java and XML, including Betwixt as well as my own JiBX framework. JAXB 
2.0 is also taking steps in this direction. The subject of the email 
exchanges has been the desirability of better GUI tools for working with 
frameworks which support such flexible conversions.

Betwixt seems to offer very good support for starting from basics and 
refining the mapping as you go. It basically offers defaults for 
everything, then lets you override the defaults. JiBX takes almost the 
opposite approach, requiring the user to specify everything (though 
there is a tool which will generate a default binding automatically, 
with a variety of overrides). I can certainly see the benefits to 
providing a tool that allows an interactive approach to building a JiBX 
binding, basically starting with Betwixt-like defaults and allowing 
overrides at every step of the way down to a detailed JiBX binding. The 
way I envision it this should show sample XML output (or the current 
schema, for those developers able to understand schemas) at every step 
of the way - when you change the binding, you immediately get the change 
reflected in the schema/sample XML. Ideally you should even be able to 
go the other way - modify the schema, and have the binding automatically 
reflect the change (or replace the schema with a new version, and have 
the binding adjust as best it can and then flag the mismatches). I've 
been adding hooks to JiBX for some time with the intent of moving it in 
this direction.

Much of the off-list discussion has revolved around the possibility of 
building a generic tool of this type, one able to work with different 
frameworks. On thinking it over, it seems to me that at least the 
general framework of the tool should be reusable - say the IDE 
integration and XML/schema display and manipulation. That would leave 
the need to write plugins for each binding framework to handle XML 
instance and schema generation from a binding and set of classes, and to 
handle editing the actual binding definition (in whatever form that 
takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).

What do people think of this? Anyone want to jump right in and start 
putting this together? ;-)

  - Dennis

Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Venkat Reddy <vr...@gmail.com>]

+1 for Dennis as Axis2 committer.

On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
> Team,
> Dennis has been a long time contributor to Axis...Let's welcome him
> with open arms to Axis2.
> 
> Here's my +1 to Dennis for Axis2 committer.
> 
> thanks,
> dims
> 
> 
> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I've been having some off-list email exchanges on the issues of better
> > tools for going between Java and XML. This is relevant to both
> > start-from-Java approaches to web services, and handling schema
> > versioning. Since these issues are important for Axis2 I'll get this
> > thread going here, assuming nobody objects to us using the Axis2 list
> > for this purpose. I'm copying the jibx-devs list on my own emails on
> > this topic just so that people monitoring that list are also aware of
> > the discussion.
> >
> > While we have a number of tools for generating Java object models to
> > (more or less) match a schema, most of these tools either cannot work
> > with pre-existing Java classes or can only work with existing classes
> > using their own built-in correspondences. This limitation makes it very
> > difficult for users to take a start-from-Java approach to developing web
> > services, since the users then have little or no control over the
> > schemas used by the web service (as seen with the JAX-RPC 1.0-style
> > doc/lit mapping). It also makes it very difficult for users to work with
> > evolving schemas, since their data model will need to be regenerated
> > every time the schema changes. Because of this, users often end up
> > writing a translation layer into their applications to take the data
> > from the schema-centric model and convert it into structures actually
> > used by their main application code.
> >
> > There are some libraries which provide more flexible conversions between
> > Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> > 2.0 is also taking steps in this direction. The subject of the email
> > exchanges has been the desirability of better GUI tools for working with
> > frameworks which support such flexible conversions.
> >
> > Betwixt seems to offer very good support for starting from basics and
> > refining the mapping as you go. It basically offers defaults for
> > everything, then lets you override the defaults. JiBX takes almost the
> > opposite approach, requiring the user to specify everything (though
> > there is a tool which will generate a default binding automatically,
> > with a variety of overrides). I can certainly see the benefits to
> > providing a tool that allows an interactive approach to building a JiBX
> > binding, basically starting with Betwixt-like defaults and allowing
> > overrides at every step of the way down to a detailed JiBX binding. The
> > way I envision it this should show sample XML output (or the current
> > schema, for those developers able to understand schemas) at every step
> > of the way - when you change the binding, you immediately get the change
> > reflected in the schema/sample XML. Ideally you should even be able to
> > go the other way - modify the schema, and have the binding automatically
> > reflect the change (or replace the schema with a new version, and have
> > the binding adjust as best it can and then flag the mismatches). I've
> > been adding hooks to JiBX for some time with the intent of moving it in
> > this direction.
> >
> > Much of the off-list discussion has revolved around the possibility of
> > building a generic tool of this type, one able to work with different
> > frameworks. On thinking it over, it seems to me that at least the
> > general framework of the tool should be reusable - say the IDE
> > integration and XML/schema display and manipulation. That would leave
> > the need to write plugins for each binding framework to handle XML
> > instance and schema generation from a binding and set of classes, and to
> > handle editing the actual binding definition (in whatever form that
> > takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> >
> > What do people think of this? Anyone want to jump right in and start
> > putting this together? ;-)
> >
> >   - Dennis
> >
> 
> 
> --
> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
>

Re: [Axis2] Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, dims asked me ahead of time and I said I was definitely interested.

Of course, that was before he -1'ed me using "dms" as my apache id...

  - Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA  425.885.7197



Aleksander Slominski wrote:

> +1
>
> if Dennis is interested then it would be great addition to Axis2 team!
>
> alek
>
> chathura@opensource.lk wrote:
>
>> here is my +1
>> Chathura
>>
>>  
>>
>>> +1,
>>> welcome Dennis :-)
>>>
>>> - Ruchith
>>>
>>> On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
>>>   
>>>
>>>> Team,
>>>> Dennis has been a long time contributor to Axis...Let's welcome him
>>>> with open arms to Axis2.
>>>>
>>>> Here's my +1 to Dennis for Axis2 committer.
>>>>
>>>> thanks,
>>>> dims
>>>>
>>>>
>>>> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>>>     
>>>>
>>>>> I've been having some off-list email exchanges on the issues of 
>>>>> better
>>>>> tools for going between Java and XML. This is relevant to both
>>>>> start-from-Java approaches to web services, and handling schema
>>>>> versioning. Since these issues are important for Axis2 I'll get this
>>>>> thread going here, assuming nobody objects to us using the Axis2 list
>>>>> for this purpose. I'm copying the jibx-devs list on my own emails on
>>>>> this topic just so that people monitoring that list are also aware of
>>>>> the discussion.
>>>>>
>>>>> While we have a number of tools for generating Java object models to
>>>>> (more or less) match a schema, most of these tools either cannot work
>>>>> with pre-existing Java classes or can only work with existing classes
>>>>> using their own built-in correspondences. This limitation makes it
>>>>>       
>>>>
>>>> very
>>>>     
>>>>
>>>>> difficult for users to take a start-from-Java approach to developing
>>>>>       
>>>>
>>>> web
>>>>     
>>>>
>>>>> services, since the users then have little or no control over the
>>>>> schemas used by the web service (as seen with the JAX-RPC 1.0-style
>>>>> doc/lit mapping). It also makes it very difficult for users to work
>>>>>       
>>>>
>>>> with
>>>>     
>>>>
>>>>> evolving schemas, since their data model will need to be regenerated
>>>>> every time the schema changes. Because of this, users often end up
>>>>> writing a translation layer into their applications to take the data
>>>>> from the schema-centric model and convert it into structures actually
>>>>> used by their main application code.
>>>>>
>>>>> There are some libraries which provide more flexible conversions
>>>>>       
>>>>
>>>> between
>>>>     
>>>>
>>>>> Java and XML, including Betwixt as well as my own JiBX framework. 
>>>>> JAXB
>>>>> 2.0 is also taking steps in this direction. The subject of the email
>>>>> exchanges has been the desirability of better GUI tools for working
>>>>>       
>>>>
>>>> with
>>>>     
>>>>
>>>>> frameworks which support such flexible conversions.
>>>>>
>>>>> Betwixt seems to offer very good support for starting from basics and
>>>>> refining the mapping as you go. It basically offers defaults for
>>>>> everything, then lets you override the defaults. JiBX takes almost 
>>>>> the
>>>>> opposite approach, requiring the user to specify everything (though
>>>>> there is a tool which will generate a default binding automatically,
>>>>> with a variety of overrides). I can certainly see the benefits to
>>>>> providing a tool that allows an interactive approach to building a
>>>>>       
>>>>
>>>> JiBX
>>>>     
>>>>
>>>>> binding, basically starting with Betwixt-like defaults and allowing
>>>>> overrides at every step of the way down to a detailed JiBX binding.
>>>>>       
>>>>
>>>> The
>>>>     
>>>>
>>>>> way I envision it this should show sample XML output (or the current
>>>>> schema, for those developers able to understand schemas) at every 
>>>>> step
>>>>> of the way - when you change the binding, you immediately get the
>>>>>       
>>>>
>>>> change
>>>>     
>>>>
>>>>> reflected in the schema/sample XML. Ideally you should even be 
>>>>> able to
>>>>> go the other way - modify the schema, and have the binding
>>>>>       
>>>>
>>>> automatically
>>>>     
>>>>
>>>>> reflect the change (or replace the schema with a new version, and 
>>>>> have
>>>>> the binding adjust as best it can and then flag the mismatches). I've
>>>>> been adding hooks to JiBX for some time with the intent of moving it
>>>>>       
>>>>
>>>> in
>>>>     
>>>>
>>>>> this direction.
>>>>>
>>>>> Much of the off-list discussion has revolved around the 
>>>>> possibility of
>>>>> building a generic tool of this type, one able to work with different
>>>>> frameworks. On thinking it over, it seems to me that at least the
>>>>> general framework of the tool should be reusable - say the IDE
>>>>> integration and XML/schema display and manipulation. That would leave
>>>>> the need to write plugins for each binding framework to handle XML
>>>>> instance and schema generation from a binding and set of classes, and
>>>>>       
>>>>
>>>> to
>>>>     
>>>>
>>>>> handle editing the actual binding definition (in whatever form that
>>>>> takes - an XML file for Betwixt and JiBX, annotations for JAXB, 
>>>>> etc.).
>>>>>
>>>>> What do people think of this? Anyone want to jump right in and start
>>>>> putting this together? ;-)
>>>>>
>>>>>  - Dennis
>>>>>
>>>>>       
>>>>
>>>> -- 
>>>> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
>>>> Platform
>>>>
>>>>     
>>>
>>> -- 
>>> Ruchith
>>>
>>>
>>>   
>>
>>
>>  
>>
>
>

Re: [VOTE] Dennis Sosnoski for Axis2 committer

[Eran Chinthaka <ch...@opensource.lk>]

+1. (Can I add more :)).

Dennis, it's nice to have someone like you with us working for Axis2.
Welcome aboard. 

-- Chinthaka

> -----Original Message-----
> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> Sent: Friday, August 19, 2005 10:25 AM
> To: axis-dev@ws.apache.org
> Subject: [Axis2] Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re:
> [Axis2] Better Java-XML mapping)
> 
> +1
> 
> if Dennis is interested then it would be great addition to Axis2 team!
> 
> alek
> 
> chathura@opensource.lk wrote:
> 
> >here is my +1
> >Chathura
> >
> >
> >
> >>+1,
> >>welcome Dennis :-)
> >>
> >>- Ruchith
> >>
> >>On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
> >>
> >>
> >>>Team,
> >>>Dennis has been a long time contributor to Axis...Let's welcome him
> >>>with open arms to Axis2.
> >>>
> >>>Here's my +1 to Dennis for Axis2 committer.
> >>>
> >>>thanks,
> >>>dims
> >>>
> >>>
> >>>On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>>
> >>>
> >>>>I've been having some off-list email exchanges on the issues of better
> >>>>tools for going between Java and XML. This is relevant to both
> >>>>start-from-Java approaches to web services, and handling schema
> >>>>versioning. Since these issues are important for Axis2 I'll get this
> >>>>thread going here, assuming nobody objects to us using the Axis2 list
> >>>>for this purpose. I'm copying the jibx-devs list on my own emails on
> >>>>this topic just so that people monitoring that list are also aware of
> >>>>the discussion.
> >>>>
> >>>>While we have a number of tools for generating Java object models to
> >>>>(more or less) match a schema, most of these tools either cannot work
> >>>>with pre-existing Java classes or can only work with existing classes
> >>>>using their own built-in correspondences. This limitation makes it
> >>>>
> >>>>
> >>>very
> >>>
> >>>
> >>>>difficult for users to take a start-from-Java approach to developing
> >>>>
> >>>>
> >>>web
> >>>
> >>>
> >>>>services, since the users then have little or no control over the
> >>>>schemas used by the web service (as seen with the JAX-RPC 1.0-style
> >>>>doc/lit mapping). It also makes it very difficult for users to work
> >>>>
> >>>>
> >>>with
> >>>
> >>>
> >>>>evolving schemas, since their data model will need to be regenerated
> >>>>every time the schema changes. Because of this, users often end up
> >>>>writing a translation layer into their applications to take the data
> >>>>from the schema-centric model and convert it into structures actually
> >>>>used by their main application code.
> >>>>
> >>>>There are some libraries which provide more flexible conversions
> >>>>
> >>>>
> >>>between
> >>>
> >>>
> >>>>Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> >>>>2.0 is also taking steps in this direction. The subject of the email
> >>>>exchanges has been the desirability of better GUI tools for working
> >>>>
> >>>>
> >>>with
> >>>
> >>>
> >>>>frameworks which support such flexible conversions.
> >>>>
> >>>>Betwixt seems to offer very good support for starting from basics and
> >>>>refining the mapping as you go. It basically offers defaults for
> >>>>everything, then lets you override the defaults. JiBX takes almost the
> >>>>opposite approach, requiring the user to specify everything (though
> >>>>there is a tool which will generate a default binding automatically,
> >>>>with a variety of overrides). I can certainly see the benefits to
> >>>>providing a tool that allows an interactive approach to building a
> >>>>
> >>>>
> >>>JiBX
> >>>
> >>>
> >>>>binding, basically starting with Betwixt-like defaults and allowing
> >>>>overrides at every step of the way down to a detailed JiBX binding.
> >>>>
> >>>>
> >>>The
> >>>
> >>>
> >>>>way I envision it this should show sample XML output (or the current
> >>>>schema, for those developers able to understand schemas) at every step
> >>>>of the way - when you change the binding, you immediately get the
> >>>>
> >>>>
> >>>change
> >>>
> >>>
> >>>>reflected in the schema/sample XML. Ideally you should even be able to
> >>>>go the other way - modify the schema, and have the binding
> >>>>
> >>>>
> >>>automatically
> >>>
> >>>
> >>>>reflect the change (or replace the schema with a new version, and have
> >>>>the binding adjust as best it can and then flag the mismatches). I've
> >>>>been adding hooks to JiBX for some time with the intent of moving it
> >>>>
> >>>>
> >>>in
> >>>
> >>>
> >>>>this direction.
> >>>>
> >>>>Much of the off-list discussion has revolved around the possibility of
> >>>>building a generic tool of this type, one able to work with different
> >>>>frameworks. On thinking it over, it seems to me that at least the
> >>>>general framework of the tool should be reusable - say the IDE
> >>>>integration and XML/schema display and manipulation. That would leave
> >>>>the need to write plugins for each binding framework to handle XML
> >>>>instance and schema generation from a binding and set of classes, and
> >>>>
> >>>>
> >>>to
> >>>
> >>>
> >>>>handle editing the actual binding definition (in whatever form that
> >>>>takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> >>>>
> >>>>What do people think of this? Anyone want to jump right in and start
> >>>>putting this together? ;-)
> >>>>
> >>>>  - Dennis
> >>>>
> >>>>
> >>>>
> >>>--
> >>>Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> >>>Platform
> >>>
> >>>
> >>>
> >>--
> >>Ruchith
> >>
> >>
> >>
> >>
> >
> >
> >
> 
> 
> --
> The best way to predict the future is to invent it - Alan Kay
> 

[Axis2] Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Aleksander Slominski <as...@cs.indiana.edu>]

+1

if Dennis is interested then it would be great addition to Axis2 team!

alek

chathura@opensource.lk wrote:

>here is my +1
>Chathura
>
>  
>
>>+1,
>>welcome Dennis :-)
>>
>>- Ruchith
>>
>>On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
>>    
>>
>>>Team,
>>>Dennis has been a long time contributor to Axis...Let's welcome him
>>>with open arms to Axis2.
>>>
>>>Here's my +1 to Dennis for Axis2 committer.
>>>
>>>thanks,
>>>dims
>>>
>>>
>>>On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>>      
>>>
>>>>I've been having some off-list email exchanges on the issues of better
>>>>tools for going between Java and XML. This is relevant to both
>>>>start-from-Java approaches to web services, and handling schema
>>>>versioning. Since these issues are important for Axis2 I'll get this
>>>>thread going here, assuming nobody objects to us using the Axis2 list
>>>>for this purpose. I'm copying the jibx-devs list on my own emails on
>>>>this topic just so that people monitoring that list are also aware of
>>>>the discussion.
>>>>
>>>>While we have a number of tools for generating Java object models to
>>>>(more or less) match a schema, most of these tools either cannot work
>>>>with pre-existing Java classes or can only work with existing classes
>>>>using their own built-in correspondences. This limitation makes it
>>>>        
>>>>
>>>very
>>>      
>>>
>>>>difficult for users to take a start-from-Java approach to developing
>>>>        
>>>>
>>>web
>>>      
>>>
>>>>services, since the users then have little or no control over the
>>>>schemas used by the web service (as seen with the JAX-RPC 1.0-style
>>>>doc/lit mapping). It also makes it very difficult for users to work
>>>>        
>>>>
>>>with
>>>      
>>>
>>>>evolving schemas, since their data model will need to be regenerated
>>>>every time the schema changes. Because of this, users often end up
>>>>writing a translation layer into their applications to take the data
>>>>from the schema-centric model and convert it into structures actually
>>>>used by their main application code.
>>>>
>>>>There are some libraries which provide more flexible conversions
>>>>        
>>>>
>>>between
>>>      
>>>
>>>>Java and XML, including Betwixt as well as my own JiBX framework. JAXB
>>>>2.0 is also taking steps in this direction. The subject of the email
>>>>exchanges has been the desirability of better GUI tools for working
>>>>        
>>>>
>>>with
>>>      
>>>
>>>>frameworks which support such flexible conversions.
>>>>
>>>>Betwixt seems to offer very good support for starting from basics and
>>>>refining the mapping as you go. It basically offers defaults for
>>>>everything, then lets you override the defaults. JiBX takes almost the
>>>>opposite approach, requiring the user to specify everything (though
>>>>there is a tool which will generate a default binding automatically,
>>>>with a variety of overrides). I can certainly see the benefits to
>>>>providing a tool that allows an interactive approach to building a
>>>>        
>>>>
>>>JiBX
>>>      
>>>
>>>>binding, basically starting with Betwixt-like defaults and allowing
>>>>overrides at every step of the way down to a detailed JiBX binding.
>>>>        
>>>>
>>>The
>>>      
>>>
>>>>way I envision it this should show sample XML output (or the current
>>>>schema, for those developers able to understand schemas) at every step
>>>>of the way - when you change the binding, you immediately get the
>>>>        
>>>>
>>>change
>>>      
>>>
>>>>reflected in the schema/sample XML. Ideally you should even be able to
>>>>go the other way - modify the schema, and have the binding
>>>>        
>>>>
>>>automatically
>>>      
>>>
>>>>reflect the change (or replace the schema with a new version, and have
>>>>the binding adjust as best it can and then flag the mismatches). I've
>>>>been adding hooks to JiBX for some time with the intent of moving it
>>>>        
>>>>
>>>in
>>>      
>>>
>>>>this direction.
>>>>
>>>>Much of the off-list discussion has revolved around the possibility of
>>>>building a generic tool of this type, one able to work with different
>>>>frameworks. On thinking it over, it seems to me that at least the
>>>>general framework of the tool should be reusable - say the IDE
>>>>integration and XML/schema display and manipulation. That would leave
>>>>the need to write plugins for each binding framework to handle XML
>>>>instance and schema generation from a binding and set of classes, and
>>>>        
>>>>
>>>to
>>>      
>>>
>>>>handle editing the actual binding definition (in whatever form that
>>>>takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
>>>>
>>>>What do people think of this? Anyone want to jump right in and start
>>>>putting this together? ;-)
>>>>
>>>>  - Dennis
>>>>
>>>>        
>>>>
>>>--
>>>Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
>>>Platform
>>>
>>>      
>>>
>>--
>>Ruchith
>>
>>
>>    
>>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay

Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[ch...@opensource.lk]

here is my +1
Chathura

> +1,
> welcome Dennis :-)
>
> - Ruchith
>
> On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
>> Team,
>> Dennis has been a long time contributor to Axis...Let's welcome him
>> with open arms to Axis2.
>>
>> Here's my +1 to Dennis for Axis2 committer.
>>
>> thanks,
>> dims
>>
>>
>> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> > I've been having some off-list email exchanges on the issues of better
>> > tools for going between Java and XML. This is relevant to both
>> > start-from-Java approaches to web services, and handling schema
>> > versioning. Since these issues are important for Axis2 I'll get this
>> > thread going here, assuming nobody objects to us using the Axis2 list
>> > for this purpose. I'm copying the jibx-devs list on my own emails on
>> > this topic just so that people monitoring that list are also aware of
>> > the discussion.
>> >
>> > While we have a number of tools for generating Java object models to
>> > (more or less) match a schema, most of these tools either cannot work
>> > with pre-existing Java classes or can only work with existing classes
>> > using their own built-in correspondences. This limitation makes it
>> very
>> > difficult for users to take a start-from-Java approach to developing
>> web
>> > services, since the users then have little or no control over the
>> > schemas used by the web service (as seen with the JAX-RPC 1.0-style
>> > doc/lit mapping). It also makes it very difficult for users to work
>> with
>> > evolving schemas, since their data model will need to be regenerated
>> > every time the schema changes. Because of this, users often end up
>> > writing a translation layer into their applications to take the data
>> > from the schema-centric model and convert it into structures actually
>> > used by their main application code.
>> >
>> > There are some libraries which provide more flexible conversions
>> between
>> > Java and XML, including Betwixt as well as my own JiBX framework. JAXB
>> > 2.0 is also taking steps in this direction. The subject of the email
>> > exchanges has been the desirability of better GUI tools for working
>> with
>> > frameworks which support such flexible conversions.
>> >
>> > Betwixt seems to offer very good support for starting from basics and
>> > refining the mapping as you go. It basically offers defaults for
>> > everything, then lets you override the defaults. JiBX takes almost the
>> > opposite approach, requiring the user to specify everything (though
>> > there is a tool which will generate a default binding automatically,
>> > with a variety of overrides). I can certainly see the benefits to
>> > providing a tool that allows an interactive approach to building a
>> JiBX
>> > binding, basically starting with Betwixt-like defaults and allowing
>> > overrides at every step of the way down to a detailed JiBX binding.
>> The
>> > way I envision it this should show sample XML output (or the current
>> > schema, for those developers able to understand schemas) at every step
>> > of the way - when you change the binding, you immediately get the
>> change
>> > reflected in the schema/sample XML. Ideally you should even be able to
>> > go the other way - modify the schema, and have the binding
>> automatically
>> > reflect the change (or replace the schema with a new version, and have
>> > the binding adjust as best it can and then flag the mismatches). I've
>> > been adding hooks to JiBX for some time with the intent of moving it
>> in
>> > this direction.
>> >
>> > Much of the off-list discussion has revolved around the possibility of
>> > building a generic tool of this type, one able to work with different
>> > frameworks. On thinking it over, it seems to me that at least the
>> > general framework of the tool should be reusable - say the IDE
>> > integration and XML/schema display and manipulation. That would leave
>> > the need to write plugins for each binding framework to handle XML
>> > instance and schema generation from a binding and set of classes, and
>> to
>> > handle editing the actual binding definition (in whatever form that
>> > takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
>> >
>> > What do people think of this? Anyone want to jump right in and start
>> > putting this together? ;-)
>> >
>> >   - Dennis
>> >
>>
>>
>> --
>> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
>> Platform
>>
>
>
> --
> Ruchith
>
>

Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Ruchith Fernando <ru...@gmail.com>]

+1,  
welcome Dennis :-)

- Ruchith 

On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
> Team,
> Dennis has been a long time contributor to Axis...Let's welcome him
> with open arms to Axis2.
> 
> Here's my +1 to Dennis for Axis2 committer.
> 
> thanks,
> dims
> 
> 
> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I've been having some off-list email exchanges on the issues of better
> > tools for going between Java and XML. This is relevant to both
> > start-from-Java approaches to web services, and handling schema
> > versioning. Since these issues are important for Axis2 I'll get this
> > thread going here, assuming nobody objects to us using the Axis2 list
> > for this purpose. I'm copying the jibx-devs list on my own emails on
> > this topic just so that people monitoring that list are also aware of
> > the discussion.
> >
> > While we have a number of tools for generating Java object models to
> > (more or less) match a schema, most of these tools either cannot work
> > with pre-existing Java classes or can only work with existing classes
> > using their own built-in correspondences. This limitation makes it very
> > difficult for users to take a start-from-Java approach to developing web
> > services, since the users then have little or no control over the
> > schemas used by the web service (as seen with the JAX-RPC 1.0-style
> > doc/lit mapping). It also makes it very difficult for users to work with
> > evolving schemas, since their data model will need to be regenerated
> > every time the schema changes. Because of this, users often end up
> > writing a translation layer into their applications to take the data
> > from the schema-centric model and convert it into structures actually
> > used by their main application code.
> >
> > There are some libraries which provide more flexible conversions between
> > Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> > 2.0 is also taking steps in this direction. The subject of the email
> > exchanges has been the desirability of better GUI tools for working with
> > frameworks which support such flexible conversions.
> >
> > Betwixt seems to offer very good support for starting from basics and
> > refining the mapping as you go. It basically offers defaults for
> > everything, then lets you override the defaults. JiBX takes almost the
> > opposite approach, requiring the user to specify everything (though
> > there is a tool which will generate a default binding automatically,
> > with a variety of overrides). I can certainly see the benefits to
> > providing a tool that allows an interactive approach to building a JiBX
> > binding, basically starting with Betwixt-like defaults and allowing
> > overrides at every step of the way down to a detailed JiBX binding. The
> > way I envision it this should show sample XML output (or the current
> > schema, for those developers able to understand schemas) at every step
> > of the way - when you change the binding, you immediately get the change
> > reflected in the schema/sample XML. Ideally you should even be able to
> > go the other way - modify the schema, and have the binding automatically
> > reflect the change (or replace the schema with a new version, and have
> > the binding adjust as best it can and then flag the mismatches). I've
> > been adding hooks to JiBX for some time with the intent of moving it in
> > this direction.
> >
> > Much of the off-list discussion has revolved around the possibility of
> > building a generic tool of this type, one able to work with different
> > frameworks. On thinking it over, it seems to me that at least the
> > general framework of the tool should be reusable - say the IDE
> > integration and XML/schema display and manipulation. That would leave
> > the need to write plugins for each binding framework to handle XML
> > instance and schema generation from a binding and set of classes, and to
> > handle editing the actual binding definition (in whatever form that
> > takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> >
> > What do people think of this? Anyone want to jump right in and start
> > putting this together? ;-)
> >
> >   - Dennis
> >
> 
> 
> --
> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
> 


-- 
Ruchith

Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Davanum Srinivas <da...@gmail.com>]

Only caveat...We should not let him use "dms" as his apache id :) too
close to "dims" :) :)

On 8/18/05, Davanum Srinivas <da...@gmail.com> wrote:
> Team,
> Dennis has been a long time contributor to Axis...Let's welcome him
> with open arms to Axis2.
> 
> Here's my +1 to Dennis for Axis2 committer.
> 
> thanks,
> dims
> 
> 
> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I've been having some off-list email exchanges on the issues of better
> > tools for going between Java and XML. This is relevant to both
> > start-from-Java approaches to web services, and handling schema
> > versioning. Since these issues are important for Axis2 I'll get this
> > thread going here, assuming nobody objects to us using the Axis2 list
> > for this purpose. I'm copying the jibx-devs list on my own emails on
> > this topic just so that people monitoring that list are also aware of
> > the discussion.
> >
> > While we have a number of tools for generating Java object models to
> > (more or less) match a schema, most of these tools either cannot work
> > with pre-existing Java classes or can only work with existing classes
> > using their own built-in correspondences. This limitation makes it very
> > difficult for users to take a start-from-Java approach to developing web
> > services, since the users then have little or no control over the
> > schemas used by the web service (as seen with the JAX-RPC 1.0-style
> > doc/lit mapping). It also makes it very difficult for users to work with
> > evolving schemas, since their data model will need to be regenerated
> > every time the schema changes. Because of this, users often end up
> > writing a translation layer into their applications to take the data
> > from the schema-centric model and convert it into structures actually
> > used by their main application code.
> >
> > There are some libraries which provide more flexible conversions between
> > Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> > 2.0 is also taking steps in this direction. The subject of the email
> > exchanges has been the desirability of better GUI tools for working with
> > frameworks which support such flexible conversions.
> >
> > Betwixt seems to offer very good support for starting from basics and
> > refining the mapping as you go. It basically offers defaults for
> > everything, then lets you override the defaults. JiBX takes almost the
> > opposite approach, requiring the user to specify everything (though
> > there is a tool which will generate a default binding automatically,
> > with a variety of overrides). I can certainly see the benefits to
> > providing a tool that allows an interactive approach to building a JiBX
> > binding, basically starting with Betwixt-like defaults and allowing
> > overrides at every step of the way down to a detailed JiBX binding. The
> > way I envision it this should show sample XML output (or the current
> > schema, for those developers able to understand schemas) at every step
> > of the way - when you change the binding, you immediately get the change
> > reflected in the schema/sample XML. Ideally you should even be able to
> > go the other way - modify the schema, and have the binding automatically
> > reflect the change (or replace the schema with a new version, and have
> > the binding adjust as best it can and then flag the mismatches). I've
> > been adding hooks to JiBX for some time with the intent of moving it in
> > this direction.
> >
> > Much of the off-list discussion has revolved around the possibility of
> > building a generic tool of this type, one able to work with different
> > frameworks. On thinking it over, it seems to me that at least the
> > general framework of the tool should be reusable - say the IDE
> > integration and XML/schema display and manipulation. That would leave
> > the need to write plugins for each binding framework to handle XML
> > instance and schema generation from a binding and set of classes, and to
> > handle editing the actual binding definition (in whatever form that
> > takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> >
> > What do people think of this? Anyone want to jump right in and start
> > putting this together? ;-)
> >
> >   - Dennis
> >
> 
> 
> --
> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
> 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Sanjiva Weerawarana <sa...@opensource.lk>]

+1! Welcome aboard Dennis .. looking forward to your great
contributions!

Sanjiva.

On Thu, 2005-08-18 at 20:23 -0400, Davanum Srinivas wrote:
> Team,
> Dennis has been a long time contributor to Axis...Let's welcome him
> with open arms to Axis2.
> 
> Here's my +1 to Dennis for Axis2 committer.
> 
> thanks,
> dims
> 
> 
> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I've been having some off-list email exchanges on the issues of better
> > tools for going between Java and XML. This is relevant to both
> > start-from-Java approaches to web services, and handling schema
> > versioning. Since these issues are important for Axis2 I'll get this
> > thread going here, assuming nobody objects to us using the Axis2 list
> > for this purpose. I'm copying the jibx-devs list on my own emails on
> > this topic just so that people monitoring that list are also aware of
> > the discussion.
> > 
> > While we have a number of tools for generating Java object models to
> > (more or less) match a schema, most of these tools either cannot work
> > with pre-existing Java classes or can only work with existing classes
> > using their own built-in correspondences. This limitation makes it very
> > difficult for users to take a start-from-Java approach to developing web
> > services, since the users then have little or no control over the
> > schemas used by the web service (as seen with the JAX-RPC 1.0-style
> > doc/lit mapping). It also makes it very difficult for users to work with
> > evolving schemas, since their data model will need to be regenerated
> > every time the schema changes. Because of this, users often end up
> > writing a translation layer into their applications to take the data
> > from the schema-centric model and convert it into structures actually
> > used by their main application code.
> > 
> > There are some libraries which provide more flexible conversions between
> > Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> > 2.0 is also taking steps in this direction. The subject of the email
> > exchanges has been the desirability of better GUI tools for working with
> > frameworks which support such flexible conversions.
> > 
> > Betwixt seems to offer very good support for starting from basics and
> > refining the mapping as you go. It basically offers defaults for
> > everything, then lets you override the defaults. JiBX takes almost the
> > opposite approach, requiring the user to specify everything (though
> > there is a tool which will generate a default binding automatically,
> > with a variety of overrides). I can certainly see the benefits to
> > providing a tool that allows an interactive approach to building a JiBX
> > binding, basically starting with Betwixt-like defaults and allowing
> > overrides at every step of the way down to a detailed JiBX binding. The
> > way I envision it this should show sample XML output (or the current
> > schema, for those developers able to understand schemas) at every step
> > of the way - when you change the binding, you immediately get the change
> > reflected in the schema/sample XML. Ideally you should even be able to
> > go the other way - modify the schema, and have the binding automatically
> > reflect the change (or replace the schema with a new version, and have
> > the binding adjust as best it can and then flag the mismatches). I've
> > been adding hooks to JiBX for some time with the intent of moving it in
> > this direction.
> > 
> > Much of the off-list discussion has revolved around the possibility of
> > building a generic tool of this type, one able to work with different
> > frameworks. On thinking it over, it seems to me that at least the
> > general framework of the tool should be reusable - say the IDE
> > integration and XML/schema display and manipulation. That would leave
> > the need to write plugins for each binding framework to handle XML
> > instance and schema generation from a binding and set of classes, and to
> > handle editing the actual binding definition (in whatever form that
> > takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> > 
> > What do people think of this? Anyone want to jump right in and start
> > putting this together? ;-)
> > 
> >   - Dennis
> > 
> 
> 

[VOTE] Dennis Sosnoski for Axis2 committer (Re: [Axis2] Better Java-XML mapping)

[Davanum Srinivas <da...@gmail.com>]

Team,
Dennis has been a long time contributor to Axis...Let's welcome him
with open arms to Axis2.

Here's my +1 to Dennis for Axis2 committer.

thanks,
dims


On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> I've been having some off-list email exchanges on the issues of better
> tools for going between Java and XML. This is relevant to both
> start-from-Java approaches to web services, and handling schema
> versioning. Since these issues are important for Axis2 I'll get this
> thread going here, assuming nobody objects to us using the Axis2 list
> for this purpose. I'm copying the jibx-devs list on my own emails on
> this topic just so that people monitoring that list are also aware of
> the discussion.
> 
> While we have a number of tools for generating Java object models to
> (more or less) match a schema, most of these tools either cannot work
> with pre-existing Java classes or can only work with existing classes
> using their own built-in correspondences. This limitation makes it very
> difficult for users to take a start-from-Java approach to developing web
> services, since the users then have little or no control over the
> schemas used by the web service (as seen with the JAX-RPC 1.0-style
> doc/lit mapping). It also makes it very difficult for users to work with
> evolving schemas, since their data model will need to be regenerated
> every time the schema changes. Because of this, users often end up
> writing a translation layer into their applications to take the data
> from the schema-centric model and convert it into structures actually
> used by their main application code.
> 
> There are some libraries which provide more flexible conversions between
> Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> 2.0 is also taking steps in this direction. The subject of the email
> exchanges has been the desirability of better GUI tools for working with
> frameworks which support such flexible conversions.
> 
> Betwixt seems to offer very good support for starting from basics and
> refining the mapping as you go. It basically offers defaults for
> everything, then lets you override the defaults. JiBX takes almost the
> opposite approach, requiring the user to specify everything (though
> there is a tool which will generate a default binding automatically,
> with a variety of overrides). I can certainly see the benefits to
> providing a tool that allows an interactive approach to building a JiBX
> binding, basically starting with Betwixt-like defaults and allowing
> overrides at every step of the way down to a detailed JiBX binding. The
> way I envision it this should show sample XML output (or the current
> schema, for those developers able to understand schemas) at every step
> of the way - when you change the binding, you immediately get the change
> reflected in the schema/sample XML. Ideally you should even be able to
> go the other way - modify the schema, and have the binding automatically
> reflect the change (or replace the schema with a new version, and have
> the binding adjust as best it can and then flag the mismatches). I've
> been adding hooks to JiBX for some time with the intent of moving it in
> this direction.
> 
> Much of the off-list discussion has revolved around the possibility of
> building a generic tool of this type, one able to work with different
> frameworks. On thinking it over, it seems to me that at least the
> general framework of the tool should be reusable - say the IDE
> integration and XML/schema display and manipulation. That would leave
> the need to write plugins for each binding framework to handle XML
> instance and schema generation from a binding and set of classes, and to
> handle editing the actual binding definition (in whatever form that
> takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> 
> What do people think of this? Anyone want to jump right in and start
> putting this together? ;-)
> 
>   - Dennis
> 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/25/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> Sorry for the delayed response. Been a busy week.

<snip>
 
> robert burrell donkin wrote:
> >java classes and primitives have a natural correspondence to types.
> >primitives naturally correspond to simple types whereas classes may
> >correspond to simple or complex types. being able to perform multiple
> >mappings of the same primitive or class is important (think about the
> >different semantic meanings that java.util.Date may have).
> >
> >
> In addition it would be nice if you could map an xml element to multiple
> fields. For instance, if I have a nillable int. I would have an
> isIntSet() and getInt() methods. I would want each one of those set
> appropriately depending on the xml.

i think that this can be addressed by using binding points
(http://people.apache.org/~rdonkin/tool/tune.html). one logical
binding point could trigger any number of operations on the instance
but hides the power and complexity for common use cases. supporting
scripting for this would be cool.
 
> >java developers naturally reuse classes. they need to be able to reuse
> >mappings either precisely or as the basis for tuning against a
> >particular schema. i see users being able to import mappings into the
> >tool (in a pluggable fashion), tuning them (by dynamic viewing schema
> >and example generation) and then saving the mappings into a library. i
> >see this import process being extensible so that import pluggings can
> >be created for existing ways of describing bindings.
> >
> >the mappings in the library would then be available for use in other
> >tool sections for example, the mapping section (which is the named
> >i've just coined for dan's cool ideas but feel free to jump in with a
> >better one). it could also be used for a simple document tool (pure
> >start-from-java, with no target schema for initial prototyping).
> >
> >
> >
> So you're thinking this tool would be a good way to tweak an initial
> object mapping? Then import it into the "mapping section" (we need
> catchy names ;)) later if you need to tweak?

+1

the import would have lots of options useful when developing the
initial mapping but these wouldn't clutter up the later phases.
 
> >i see this design element as having advantages for the project as
> >well. mappings for common objects would be something that would be
> >easy to contribute. in addition, the numerous standard mappings which
> >it would be very good to ship with could be developed using the tool.
> >
> >comments welcomed and cool new ideas even more so :)
> >
> >dan has posted some very interesting ideas and i'd like to come back
> >to them later (maybe when i've played about with some visualisation
> >code).
> >
> >i also have some ideas about the tuning process (arising out of the
> >prototype) but i'd prefer to hear comments first before elaborating.
> >
> >
> I'd be interested in hearing your further thoughts :-).
> 
> As I think about this more, I'm coming to more conclusions. I want to be
> able to do schema first, but for my first iteration of nearly any
> project I'll be doing Java first and a nice default schema. Your mapper
> could be used to come up with that first schema & mapping.
> 
> I'll then probably want to tweak and customize it. That would probably
> require the mapping editor I described previously.

+1

that's the way i see things too :)

import for quick prototyping then the mapping for detailed work
against a schema. a lot of features that i'd want to provide for
import shouldn't be needed for the mapping. conversely, there's quite
a lot that we'd want to provide in the mapper that would IMHO just get
in the way for import.

>> Also, the more I think about it the more I want it tightly integrated
> with my IDE. As I mentioned before we can integrate refactoring. You
> could have the IDE warn you if you were creating an incompatabile schema
> change (by adding/renaming/removing a field). You could then say "create
> a new schema version" or "screw backward compatability" or if possible
> "update my mapping appropriately."

very powerful and very cool :)

would want to be able to run the components as a standard alone tool
but there's no reason why this couldn't be done by stripping down.

- robert

Re: [Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[Dennis Sosnoski <dm...@sosnoski.com>]

Another +1 for Eclipse.

There's a related Eclipse issue I'm trying to find out about - 
optionally adding debug information *for the binding* to class files 
that have been modified by JiBX (in other words, line numbers and source 
file reference for the binding definition rather than the usual Java 
source file). I'm curious whether the Eclipse debugger architecture is 
flexible enough to allow stepping through the binding during debugging. 
I think it'd really blow some minds open if this could be done, and tie 
in really well as a way of linking items in the XML output back to the 
binding definition.

Right now there's a minimally functional Eclipse plugin for JiBX, but 
it's contributed code I haven't looked into. I started writing my own 
version of a plugin a long time ago before getting sidetracked.

  - Dennis

Dan Diephouse wrote:

> I'm not that experienced with eclipse plugins, but I think 
> theoretically we should be able to do a standalone version and a 
> plugin version if it is developed as an eclipse plugin. The standalone 
> version just wouldn't get the refactoring capabilities.
>
> - Dan
>
> Davanum Srinivas wrote:
>
>> +1 for at least eclipse. folks want to do IDEA, thats fine too. don't
>> think we need a standalone ui (done it before, not worth the effort :)
>>
>> -- dims
>>  
>>
>> On 8/25/05, Dan Diephouse <da...@envoisolutions.com> wrote:
>>  
>>
>>> Dan Diephouse wrote:
>>>
>>>   
>>>
>>>> Also, the more I think about it the more I want it tightly integrated
>>>> with my IDE. As I mentioned before we can integrate refactoring. You
>>>> could have the IDE warn you if you were creating an incompatabile
>>>> schema change (by adding/renaming/removing a field). You could then
>>>> say "create a new schema version" or "screw backward compatability" or
>>>> if possible "update my mapping appropriately."
>>>>
>>>> - Dan
>>>>
>>>>     
>>>
>>> Replying to my own message...
>>>
>>> What do people think of using Eclipse for this tool? They obviously 
>>> have
>>> a great plugin architecture. Also there is a good amount of code in the
>>> Web Tools Platform Project (http://www.eclipse.org/webtools/) that 
>>> could
>>> probably be reused.
>>>
>>> Would there be a way to tightly integrate this into an IDE and have it
>>> work in both IDEA & Eclipse? Or should this be standalone?
>>>
>>> - Dan
>>>
>>> -- 
>>> Dan Diephouse
>>> Envoi Solutions LLC
>>> http://netzooid.com
>>>
>>>
>>>   
>>
>>
>>
>>  
>>
>
>

Re: [Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[robert burrell donkin <ro...@gmail.com>]

On 8/25/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> I'm not that experienced with eclipse plugins, but I think theoretically
> we should be able to do a standalone version and a plugin version if it
> is developed as an eclipse plugin. The standalone version just wouldn't
> get the refactoring capabilities.

that's what i'd hope :)

> Davanum Srinivas wrote:
> 
> >+1 for at least eclipse. folks want to do IDEA, thats fine too. 

+1

> don't think we need a standalone ui (done it before, not worth the effort :)

a basic standalone version would be useful. would want to be able to
get stuff up for people to play with quickly (i find it hard to think
about gui's in the abstract) and that'd be easier initially with a
standalone.

- robert

Re: [Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[robert burrell donkin <ro...@gmail.com>]

On 8/26/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi Dan,
>  I'm not a hardcore Eclipse guy but I've done some Eclipse work (including
> the Axis2 ones :)) and have some knowledge of how Eclipse works. when
> Eclipse GUI' s are needed (Lets say an editor winow) it has to implement an
> Eclipse specific interface. because of this it is not really possible to
> share it as a plugin and a standalone as-is!.
>  My approach to both the Axis2 plugin's was to have a 'core' which
> implements the basic function of the tool. The eclipse version have the UI's
> implemented in the Eclipse specific way and the swing vesrion has the UI
> implemented in it's own way. All of them call the core functions to do the
> work.
>  My guess is we should be taking a similar approach if we are to ship
> different UI versions of the same tool.

thanks for the information :)

i wondered whether it might be possible to ship a standalone version
based on the eclipse platform just packaged as an application rather
than a plugin but maybe swing would have some other advantages for
myself. i don't really know anything about the eclipse internals and
i'd need to learn that. i'd be much quicker hacking a prototype
together in swing (which i know well).

i'd be interested in learning what people think of the applet examples
as a way of developing a design ideas. one approach would be for me to
develop more complex swing examples of the ideas.

>  BTW I'm really interested in this tool Idea. As I mentioned in one of my
> earlier mails it's an area we have to make  improvements :)

cool :)

hopefully we might be able to find some gui gurus who fancy taking on
this fertile ground...

- robert

Re: [Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[Ajith Ranabahu <aj...@gmail.com>]

Hi Dan,
I'm not a hardcore Eclipse guy but I've done some Eclipse work (including 
the Axis2 ones :)) and have some knowledge of how Eclipse works. when 
Eclipse GUI' s are needed (Lets say an editor winow) it has to implement an 
Eclipse specific interface. because of this it is not really possible to 
share it as a plugin and a standalone as-is!.
My approach to both the Axis2 plugin's was to have a 'core' which implements 
the basic function of the tool. The eclipse version have the UI's 
implemented in the Eclipse specific way and the swing vesrion has the UI 
implemented in it's own way. All of them call the core functions to do the 
work.
My guess is we should be taking a similar approach if we are to ship 
different UI versions of the same tool.
BTW I'm really interested in this tool Idea. As I mentioned in one of my 
earlier mails it's an area we have to make improvements :)

On 8/26/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> 
> I'm not that experienced with eclipse plugins, but I think theoretically
> we should be able to do a standalone version and a plugin version if it
> is developed as an eclipse plugin. The standalone version just wouldn't
> get the refactoring capabilities.
> 
> - Dan
> 
> Davanum Srinivas wrote:
> 
> >+1 for at least eclipse. folks want to do IDEA, thats fine too. don't
> >think we need a standalone ui (done it before, not worth the effort :)
> >
> >-- dims
> >
> >
> >On 8/25/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> >
> >
> >>Dan Diephouse wrote:
> >>
> >>
> >>
> >>>Also, the more I think about it the more I want it tightly integrated
> >>>with my IDE. As I mentioned before we can integrate refactoring. You
> >>>could have the IDE warn you if you were creating an incompatabile
> >>>schema change (by adding/renaming/removing a field). You could then
> >>>say "create a new schema version" or "screw backward compatability" or
> >>>if possible "update my mapping appropriately."
> >>>
> >>>- Dan
> >>>
> >>>
> >>>
> >>Replying to my own message...
> >>
> >>What do people think of using Eclipse for this tool? They obviously have
> >>a great plugin architecture. Also there is a good amount of code in the
> >>Web Tools Platform Project (http://www.eclipse.org/webtools/) that could
> >>probably be reused.
> >>
> >>Would there be a way to tightly integrate this into an IDE and have it
> >>work in both IDEA & Eclipse? Or should this be standalone?
> >>
> >>- Dan
> >>
> >>--
> >>Dan Diephouse
> >>Envoi Solutions LLC
> >>http://netzooid.com
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 
> --
> Dan Diephouse
> Envoi Solutions LLC
> http://netzooid.com
> 
> 


-- 
Ajith Ranabahu

Re: [Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[Dan Diephouse <da...@envoisolutions.com>]

I'm not that experienced with eclipse plugins, but I think theoretically 
we should be able to do a standalone version and a plugin version if it 
is developed as an eclipse plugin. The standalone version just wouldn't 
get the refactoring capabilities.

- Dan

Davanum Srinivas wrote:

>+1 for at least eclipse. folks want to do IDEA, thats fine too. don't
>think we need a standalone ui (done it before, not worth the effort :)
>
>-- dims
>  
>
>On 8/25/05, Dan Diephouse <da...@envoisolutions.com> wrote:
>  
>
>>Dan Diephouse wrote:
>>
>>    
>>
>>>Also, the more I think about it the more I want it tightly integrated
>>>with my IDE. As I mentioned before we can integrate refactoring. You
>>>could have the IDE warn you if you were creating an incompatabile
>>>schema change (by adding/renaming/removing a field). You could then
>>>say "create a new schema version" or "screw backward compatability" or
>>>if possible "update my mapping appropriately."
>>>
>>>- Dan
>>>
>>>      
>>>
>>Replying to my own message...
>>
>>What do people think of using Eclipse for this tool? They obviously have
>>a great plugin architecture. Also there is a good amount of code in the
>>Web Tools Platform Project (http://www.eclipse.org/webtools/) that could
>>probably be reused.
>>
>>Would there be a way to tightly integrate this into an IDE and have it
>>work in both IDEA & Eclipse? Or should this be standalone?
>>
>>- Dan
>>
>>--
>>Dan Diephouse
>>Envoi Solutions LLC
>>http://netzooid.com
>>
>>
>>    
>>
>
>
>  
>


-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com

Re: [Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[Davanum Srinivas <da...@gmail.com>]

+1 for at least eclipse. folks want to do IDEA, thats fine too. don't
think we need a standalone ui (done it before, not worth the effort :)

-- dims

On 8/25/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> Dan Diephouse wrote:
> 
> > Also, the more I think about it the more I want it tightly integrated
> > with my IDE. As I mentioned before we can integrate refactoring. You
> > could have the IDE warn you if you were creating an incompatabile
> > schema change (by adding/renaming/removing a field). You could then
> > say "create a new schema version" or "screw backward compatability" or
> > if possible "update my mapping appropriately."
> >
> > - Dan
> >
> Replying to my own message...
> 
> What do people think of using Eclipse for this tool? They obviously have
> a great plugin architecture. Also there is a good amount of code in the
> Web Tools Platform Project (http://www.eclipse.org/webtools/) that could
> probably be reused.
> 
> Would there be a way to tightly integrate this into an IDE and have it
> work in both IDEA & Eclipse? Or should this be standalone?
> 
> - Dan
> 
> --
> Dan Diephouse
> Envoi Solutions LLC
> http://netzooid.com
> 
> 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

[Axis2] Eclipse for Java-XML tool [was Better Java-XML mapping]

[Dan Diephouse <da...@envoisolutions.com>]

Dan Diephouse wrote:

> Also, the more I think about it the more I want it tightly integrated 
> with my IDE. As I mentioned before we can integrate refactoring. You 
> could have the IDE warn you if you were creating an incompatabile 
> schema change (by adding/renaming/removing a field). You could then 
> say "create a new schema version" or "screw backward compatability" or 
> if possible "update my mapping appropriately."
>
> - Dan
>
Replying to my own message...

What do people think of using Eclipse for this tool? They obviously have 
a great plugin architecture. Also there is a good amount of code in the 
Web Tools Platform Project (http://www.eclipse.org/webtools/) that could 
probably be reused.

Would there be a way to tightly integrate this into an IDE and have it 
work in both IDEA & Eclipse? Or should this be standalone?

- Dan

-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com

Re: [Axis2] Better Java-XML mapping

[Dan Diephouse <da...@envoisolutions.com>]

Sorry for the delayed response. Been a busy week.

robert burrell donkin wrote:

>i've been playing around with some code for a day or two
>(http://people.apache.org/~rdonkin/tool.html). it's just hacked
>together but hopefully it'll serve as an illustration and act as a
>lightning rod for ideas. (it'll try to explain where i see it fitting
>into the bigger picture later.) so please criticise the concepts not
>the coding :)
>
>  
>
Cool :-)

>java classes and primitives have a natural correspondence to types.
>primitives naturally correspond to simple types whereas classes may
>correspond to simple or complex types. being able to perform multiple
>mappings of the same primitive or class is important (think about the
>different semantic meanings that java.util.Date may have).
>  
>
In addition it would be nice if you could map an xml element to multiple 
fields. For instance, if I have a nillable int. I would have an 
isIntSet() and getInt() methods. I would want each one of those set 
appropriately depending on the xml.

>java developers naturally reuse classes. they need to be able to reuse
>mappings either precisely or as the basis for tuning against a
>particular schema. i see users being able to import mappings into the
>tool (in a pluggable fashion), tuning them (by dynamic viewing schema
>and example generation) and then saving the mappings into a library. i
>see this import process being extensible so that import pluggings can
>be created for existing ways of describing bindings.
>
>the mappings in the library would then be available for use in other
>tool sections for example, the mapping section (which is the named
>i've just coined for dan's cool ideas but feel free to jump in with a
>better one). it could also be used for a simple document tool (pure
>start-from-java, with no target schema for initial prototyping).
>
>  
>
So you're thinking this tool would be a good way to tweak an initial 
object mapping? Then import it into the "mapping section" (we need 
catchy names ;)) later if you need to tweak?

>i see this design element as having advantages for the project as
>well. mappings for common objects would be something that would be
>easy to contribute. in addition, the numerous standard mappings which
>it would be very good to ship with could be developed using the tool.
>
>comments welcomed and cool new ideas even more so :)
>
>dan has posted some very interesting ideas and i'd like to come back
>to them later (maybe when i've played about with some visualisation
>code).
>
>i also have some ideas about the tuning process (arising out of the
>prototype) but i'd prefer to hear comments first before elaborating.
>  
>
I'd be interested in hearing your further thoughts :-).

As I think about this more, I'm coming to more conclusions. I want to be 
able to do schema first, but for my first iteration of nearly any 
project I'll be doing Java first and a nice default schema. Your mapper 
could be used to come up with that first schema & mapping.

I'll then probably want to tweak and customize it. That would probably 
require the mapping editor I described previously.

Also, the more I think about it the more I want it tightly integrated 
with my IDE. As I mentioned before we can integrate refactoring. You 
could have the IDE warn you if you were creating an incompatabile schema 
change (by adding/renaming/removing a field). You could then say "create 
a new schema version" or "screw backward compatability" or if possible 
"update my mapping appropriately."

- Dan

-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/24/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> robert burrell donkin wrote:
> 
> > <snip>
> >
> >
> >i've been playing around with some code for a day or two
> >(http://people.apache.org/~rdonkin/tool.html). it's just hacked
> >together but hopefully it'll serve as an illustration and act as a
> >lightning rod for ideas. (it'll try to explain where i see it fitting
> >into the bigger picture later.) so please criticise the concepts not
> >the coding :)
> >
> >
> Looks very cool to me, Robert! It'd be easy to translate your
> <class-model> structure into JiBX binding terms, too.

hoped that'd be the case :)
 
about half of betwixt is about the introspection and there's a lot
there that can be very productively mined. i'd see the import process
as being pluggable so support can be added for other formats. for
example, annotated classes or the looser style of mappings that most
betwixt users adopt (these are partly specific and partly guessed).

> I've thought about the issue of sample instances you mention on the
> page, but don't have any good answers. It'd be easy to do something for
> simple bean/struct classes - but that breaks down when you get to
> complex structures (think hashmaps, for instance). Allowing serialized
> instances to be loaded is the only thing I can think of that will work
> over a wide range of objects. Or perhaps unmarshalling an XML document
> to create instances? That way people could generate an initial XML and
> start editing it, then have the changes reflected in the object state.

yep

instance population isn't core so i don't think that a good bean
editor needs to be a priority. probably needs to be pluggable. that
way, it'd easy to add support for third party tools. i've experimented
with dynamically loading a user specified factory class and this
approach works but feels a little clumsy. i do like seeing the example
populated and IMHO we have enough ideas to justify adding this
feature.

- robert

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/26/05, Manoj Mallawaarachchie <li...@gmail.com> wrote:
> Hi,
> 
> Is this similer to SOAP Encoding. I mean type mapping with XML and
> java objects.?

this thread rose originally tangentially from SOAP encoding issues.
it's concerns the start-from-java approach to mapping xml and java
objects. the idea is that you take POJOs and use a tool to map then
directly to xml (rather than using intermediary objects).

> I'm going to work with SOAP encoding . Any Input i can get from this.?

not sure

- robert

Re: [Axis2] Better Java-XML mapping

[Manoj Mallawaarachchie <li...@gmail.com>]

Hi,

Is this similer to SOAP Encoding. I mean type mapping with XML and
java objects.?
I'm going to work with SOAP encoding . Any Input i can get from this.?

BR,
Manoj



On 8/26/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> Dennis Sosnoski wrote:
> 
> > robert burrell donkin wrote:
> >
> >> <snip>
> >>
> >>
> >> i've been playing around with some code for a day or two
> >> (http://people.apache.org/~rdonkin/tool.html). it's just hacked
> >> together but hopefully it'll serve as an illustration and act as a
> >> lightning rod for ideas. (it'll try to explain where i see it fitting
> >> into the bigger picture later.) so please criticise the concepts not
> >> the coding :)
> >>
> >>
> > Looks very cool to me, Robert! It'd be easy to translate your
> > <class-model> structure into JiBX binding terms, too.
> >
> > I've thought about the issue of sample instances you mention on the
> > page, but don't have any good answers. It'd be easy to do something
> > for simple bean/struct classes - but that breaks down when you get to
> > complex structures (think hashmaps, for instance). Allowing serialized
> > instances to be loaded is the only thing I can think of that will work
> > over a wide range of objects. Or perhaps unmarshalling an XML document
> > to create instances? That way people could generate an initial XML and
> > start editing it, then have the changes reflected in the object state.
> 
> I think editing the initial XML then marshalling it is probably the best
> way. Although I'm not convinced that something more than sample values
> are needed to see what the XML looks like.
> 
> If this tool is integrated tightly with an IDE there are probably some
> good components that we could leverate to allow inspection of types like
> HashMaps or beans.
> 
> - Dan
> 
> --
> Dan Diephouse
> Envoi Solutions LLC
> http://netzooid.com
> 
> 


-- 
use the FORCE read the SOURCE
www.linux.lk

Re: [Axis2] Better Java-XML mapping

[Dan Diephouse <da...@envoisolutions.com>]

Dennis Sosnoski wrote:

> robert burrell donkin wrote:
>
>> <snip>
>>
>>
>> i've been playing around with some code for a day or two
>> (http://people.apache.org/~rdonkin/tool.html). it's just hacked
>> together but hopefully it'll serve as an illustration and act as a
>> lightning rod for ideas. (it'll try to explain where i see it fitting
>> into the bigger picture later.) so please criticise the concepts not
>> the coding :)
>>  
>>
> Looks very cool to me, Robert! It'd be easy to translate your 
> <class-model> structure into JiBX binding terms, too.
>
> I've thought about the issue of sample instances you mention on the 
> page, but don't have any good answers. It'd be easy to do something 
> for simple bean/struct classes - but that breaks down when you get to 
> complex structures (think hashmaps, for instance). Allowing serialized 
> instances to be loaded is the only thing I can think of that will work 
> over a wide range of objects. Or perhaps unmarshalling an XML document 
> to create instances? That way people could generate an initial XML and 
> start editing it, then have the changes reflected in the object state.

I think editing the initial XML then marshalling it is probably the best 
way. Although I'm not convinced that something more than sample values 
are needed to see what the XML looks like.

If this tool is integrated tightly with an IDE there are probably some 
good components that we could leverate to allow inspection of types like 
HashMaps or beans.

- Dan

-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com

Re: [Axis2] Better Java-XML mapping

[Dennis Sosnoski <dm...@sosnoski.com>]

robert burrell donkin wrote:

> <snip>
>
>
>i've been playing around with some code for a day or two
>(http://people.apache.org/~rdonkin/tool.html). it's just hacked
>together but hopefully it'll serve as an illustration and act as a
>lightning rod for ideas. (it'll try to explain where i see it fitting
>into the bigger picture later.) so please criticise the concepts not
>the coding :)
>  
>
Looks very cool to me, Robert! It'd be easy to translate your 
<class-model> structure into JiBX binding terms, too.

I've thought about the issue of sample instances you mention on the 
page, but don't have any good answers. It'd be easy to do something for 
simple bean/struct classes - but that breaks down when you get to 
complex structures (think hashmaps, for instance). Allowing serialized 
instances to be loaded is the only thing I can think of that will work 
over a wide range of objects. Or perhaps unmarshalling an XML document 
to create instances? That way people could generate an initial XML and 
start editing it, then have the changes reflected in the object state.

  - Dennis

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/21/05, robert burrell donkin <ro...@gmail.com> wrote:
> On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I've been having some off-list email exchanges on the issues of better
> > tools for going between Java and XML. This is relevant to both
> > start-from-Java approaches to web services, and handling schema
> > versioning. Since these issues are important for Axis2 I'll get this
> > thread going here, assuming nobody objects to us using the Axis2 list
> > for this purpose. I'm copying the jibx-devs list on my own emails on
> > this topic just so that people monitoring that list are also aware of
> > the discussion.
> >
> > While we have a number of tools for generating Java object models to
> > (more or less) match a schema, most of these tools either cannot work
> > with pre-existing Java classes or can only work with existing classes
> > using their own built-in correspondences. This limitation makes it very
> > difficult for users to take a start-from-Java approach to developing web
> > services, since the users then have little or no control over the
> > schemas used by the web service (as seen with the JAX-RPC 1.0-style
> > doc/lit mapping). It also makes it very difficult for users to work with
> > evolving schemas, since their data model will need to be regenerated
> > every time the schema changes. Because of this, users often end up
> > writing a translation layer into their applications to take the data
> > from the schema-centric model and convert it into structures actually
> > used by their main application code.
> >
> > There are some libraries which provide more flexible conversions between
> > Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> > 2.0 is also taking steps in this direction. The subject of the email
> > exchanges has been the desirability of better GUI tools for working with
> > frameworks which support such flexible conversions.
> >
> > Betwixt seems to offer very good support for starting from basics and
> > refining the mapping as you go. It basically offers defaults for
> > everything, then lets you override the defaults. JiBX takes almost the
> > opposite approach, requiring the user to specify everything (though
> > there is a tool which will generate a default binding automatically,
> > with a variety of overrides). I can certainly see the benefits to
> > providing a tool that allows an interactive approach to building a JiBX
> > binding, basically starting with Betwixt-like defaults and allowing
> > overrides at every step of the way down to a detailed JiBX binding. The
> > way I envision it this should show sample XML output (or the current
> > schema, for those developers able to understand schemas) at every step
> > of the way - when you change the binding, you immediately get the change
> > reflected in the schema/sample XML. Ideally you should even be able to
> > go the other way - modify the schema, and have the binding automatically
> > reflect the change (or replace the schema with a new version, and have
> > the binding adjust as best it can and then flag the mismatches). I've
> > been adding hooks to JiBX for some time with the intent of moving it in
> > this direction.
> >
> > Much of the off-list discussion has revolved around the possibility of
> > building a generic tool of this type, one able to work with different
> > frameworks. On thinking it over, it seems to me that at least the
> > general framework of the tool should be reusable - say the IDE
> > integration and XML/schema display and manipulation. That would leave
> > the need to write plugins for each binding framework to handle XML
> > instance and schema generation from a binding and set of classes, and to
> > handle editing the actual binding definition (in whatever form that
> > takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> 
> +1
> 
> a tool makes sense and would be useful relatively quickly (even when
> not fully featured).
> 
> probably going to need to think about managing IDE integration. this
> is something that i know nothing about. do we start with one target
> and then try to add support?
> 
> > What do people think of this? Anyone want to jump right in and start
> > putting this together? ;-)
> 
> on the basis that it's easier to argue about bad code than no code,
> i'll put together a very basic protoype using betwixt (which will do
> most of the stuff required already) just using basic swing. i'm very
> interested in dan's ideas and have a list of additional features that
> IMO are needed to make it useful but a least it'd be a start.

i've been playing around with some code for a day or two
(http://people.apache.org/~rdonkin/tool.html). it's just hacked
together but hopefully it'll serve as an illustration and act as a
lightning rod for ideas. (it'll try to explain where i see it fitting
into the bigger picture later.) so please criticise the concepts not
the coding :)

java classes and primitives have a natural correspondence to types.
primitives naturally correspond to simple types whereas classes may
correspond to simple or complex types. being able to perform multiple
mappings of the same primitive or class is important (think about the
different semantic meanings that java.util.Date may have).

java developers naturally reuse classes. they need to be able to reuse
mappings either precisely or as the basis for tuning against a
particular schema. i see users being able to import mappings into the
tool (in a pluggable fashion), tuning them (by dynamic viewing schema
and example generation) and then saving the mappings into a library. i
see this import process being extensible so that import pluggings can
be created for existing ways of describing bindings.

the mappings in the library would then be available for use in other
tool sections for example, the mapping section (which is the named
i've just coined for dan's cool ideas but feel free to jump in with a
better one). it could also be used for a simple document tool (pure
start-from-java, with no target schema for initial prototyping).

i see this design element as having advantages for the project as
well. mappings for common objects would be something that would be
easy to contribute. in addition, the numerous standard mappings which
it would be very good to ship with could be developed using the tool.

comments welcomed and cool new ideas even more so :)

dan has posted some very interesting ideas and i'd like to come back
to them later (maybe when i've played about with some visualisation
code).

i also have some ideas about the tuning process (arising out of the
prototype) but i'd prefer to hear comments first before elaborating.

- robert

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> I've been having some off-list email exchanges on the issues of better
> tools for going between Java and XML. This is relevant to both
> start-from-Java approaches to web services, and handling schema
> versioning. Since these issues are important for Axis2 I'll get this
> thread going here, assuming nobody objects to us using the Axis2 list
> for this purpose. I'm copying the jibx-devs list on my own emails on
> this topic just so that people monitoring that list are also aware of
> the discussion.
> 
> While we have a number of tools for generating Java object models to
> (more or less) match a schema, most of these tools either cannot work
> with pre-existing Java classes or can only work with existing classes
> using their own built-in correspondences. This limitation makes it very
> difficult for users to take a start-from-Java approach to developing web
> services, since the users then have little or no control over the
> schemas used by the web service (as seen with the JAX-RPC 1.0-style
> doc/lit mapping). It also makes it very difficult for users to work with
> evolving schemas, since their data model will need to be regenerated
> every time the schema changes. Because of this, users often end up
> writing a translation layer into their applications to take the data
> from the schema-centric model and convert it into structures actually
> used by their main application code.
> 
> There are some libraries which provide more flexible conversions between
> Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> 2.0 is also taking steps in this direction. The subject of the email
> exchanges has been the desirability of better GUI tools for working with
> frameworks which support such flexible conversions.
> 
> Betwixt seems to offer very good support for starting from basics and
> refining the mapping as you go. It basically offers defaults for
> everything, then lets you override the defaults. JiBX takes almost the
> opposite approach, requiring the user to specify everything (though
> there is a tool which will generate a default binding automatically,
> with a variety of overrides). I can certainly see the benefits to
> providing a tool that allows an interactive approach to building a JiBX
> binding, basically starting with Betwixt-like defaults and allowing
> overrides at every step of the way down to a detailed JiBX binding. The
> way I envision it this should show sample XML output (or the current
> schema, for those developers able to understand schemas) at every step
> of the way - when you change the binding, you immediately get the change
> reflected in the schema/sample XML. Ideally you should even be able to
> go the other way - modify the schema, and have the binding automatically
> reflect the change (or replace the schema with a new version, and have
> the binding adjust as best it can and then flag the mismatches). I've
> been adding hooks to JiBX for some time with the intent of moving it in
> this direction.
> 
> Much of the off-list discussion has revolved around the possibility of
> building a generic tool of this type, one able to work with different
> frameworks. On thinking it over, it seems to me that at least the
> general framework of the tool should be reusable - say the IDE
> integration and XML/schema display and manipulation. That would leave
> the need to write plugins for each binding framework to handle XML
> instance and schema generation from a binding and set of classes, and to
> handle editing the actual binding definition (in whatever form that
> takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).

+1

a tool makes sense and would be useful relatively quickly (even when
not fully featured).

probably going to need to think about managing IDE integration. this
is something that i know nothing about. do we start with one target
and then try to add support?
 
> What do people think of this? Anyone want to jump right in and start
> putting this together? ;-)

on the basis that it's easier to argue about bad code than no code,
i'll put together a very basic protoype using betwixt (which will do
most of the stuff required already) just using basic swing. i'm very
interested in dan's ideas and have a list of additional features that
IMO are needed to make it useful but a least it'd be a start.

- robert

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/19/05, Dan Diephouse <da...@envoisolutions.com> wrote:

<snip>

> To clarify the use cases:
> 1. Schema exists, but no java code
> 2. Java code exists, but no schema
> 3. Both schema and java exist.
> How do we map between them, even when there is very little correlation
> betwen java and schema. Each one is pretty important I think.
> 
> I see something a bit different then Dennis. (now where is my virtual
> white board....) On the left pane I would see a structural
> representation of the schema portions. In the middle is a place to apply
> "actions" to a chunk of schema. On the right I would see a list of
> actions. Actions would be "create object," "set property," or even "run
> this piece of java code (via janino, groovy or the like)".
> 
> Say I have a schema like so:
>   <xsd:complexType name="book">
>     <xsd:sequence>
>       <xsd:element name="author" type="xsd:string"/>
>       <xsd:element name="title" type="xsd:string"/>
>     </xsd:sequence>
>   </xsd:complexType>
> 
> I'd see this on the left (with the option to view the schema source)
> + book
> |- author
> |- title

i've been playing around with ideas this week. i've come to the
conclusion that abstract representation is vital. what was worrying me
for a little while is that different schemas can be equivalent for
java mapping purpose. for example, consider two similar schemas which
differ only by choice of whether to define a complex type anonymously.
a more abstract representation of the schema would help users focus on
the mapping and help the tool to guess correctly.

this idea can also be applied on the object side. i've added some
thoughts to http://people.apache.org/~rdonkin/tool/tune.html (together
with another demonstration applet).

representations like these on both sides would allow easy and efficent
wiring to be created. so, rather than clicking on 'setProperty', i'd
see the user just choosing to add a pipe between the xml and the
binding point. this would allow intermediary steps to be added easily
which may be library pipes or scripts.

- robert

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/21/05, robert burrell donkin <ro...@gmail.com> wrote:
> On 8/19/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > Dan Diephouse wrote:

<snip>

> > > How do we map between them, even when there is very little correlation
> > > betwen java and schema. Each one is pretty important I think.
> > >
> > > I see something a bit different then Dennis. (now where is my virtual
> > > white board....) On the left pane I would see a structural
> > > representation of the schema portions. In the middle is a place to
> > > apply "actions" to a chunk of schema. On the right I would see a list
> > > of actions. Actions would be "create object," "set property," or even
> > > "run this piece of java code (via janino, groovy or the like)".
> 
> +1
> 
> definitely a fourth generation feature :)
> 
> this is similar to the achitecture used by the second (refactored)
> betwixt engine. i suspect that JIBX also uses something similar
> (though probably uses different terms).  with beans, you reach a stage
> where scripting becomes important. (betwixt doesn't do any of that but
> the structure's there.) the problem is that for this to be useful
> requires good tools.
> 
> i didn't see the connection before but this needs to be a core
> feature. IMHO this power would need to be pluggable so that a useful
> core toolset (probably bean and field centric if we start from what
> JIBX and betwixt have now) could be created quickly.
> 
> > > Say I have a schema like so:
> > >  <xsd:complexType name="book">
> > >    <xsd:sequence>
> > >      <xsd:element name="author" type="xsd:string"/>
> > >      <xsd:element name="title" type="xsd:string"/>
> > >    </xsd:sequence>
> > >  </xsd:complexType>
> > >
> > > I'd see this on the left (with the option to view the schema source)
> > > + book
> > > |- author
> > > |- title
> > >
> > > When I selected book I would see the middle pane pop up with different
> > > events like "on start of tag", "on end of tag", or on body. I'd be
> > > able to drag in different actions from the right to certain events and
> > > customize them. So on book I'd drag in "create object" and specify the
> > > "Book" object. On the author element I'd want to do a set property. It
> > > would also be intelligent enough create a mapping for a POJO
> > > automatically if it can.
> >
> > I like that idea a lot!
> 
> +1

interesting idea: start-from-schema but reusing start-from-java binding tools. 

we'd still want the kind of classic start-from-java builder outlined
by dennis, though.

one of the wrinkles is being able to recreate complex object graphs.
the value to set on the property needs to wired up somehow. be harder
to guess well than the start-from-java case, though. due to the
complexity of the possible constructions available to schema writers,
probably the user would need to specify most of the mappings manually.

- robert

Re: [Axis2] Better Java-XML mapping

[robert burrell donkin <ro...@gmail.com>]

On 8/19/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Dan Diephouse wrote:
> 
> > Dennis Sosnoski wrote:
> >
> >> While we have a number of tools for generating Java object models to
> >> (more or less) match a schema, most of these tools either cannot work
> >> with pre-existing Java classes or can only work with existing classes
> >> using their own built-in correspondences.
> >> ...
> >
> >
> > Agreed. I would add that I see that this is a problem with nearly all
> > approaches. Even when parsing the XML by hand, you need to have
> > seperate code for each version unless you're doing transformations.
> > DTOs are generally the same way.
> >
> > I don't view the DTO layer as necessarily a bad thing. If you're
> > schema and internal API are a lot different (which they often are), it
> > can make translation a lot easier. And it'd still be nice to map
> > multiple schemas to one set of DTOs.
> 
> JiBX can actually handle both these cases directly (direct binding to
> business model objects without the use of DTOs, and multiple schemas to
> a single set of objects). The binding definitions effectively serve the
> same purpose as transfer code or XSLT transformations (within limits).
> Of course, this creates the need to maintain the binding definitions -
> hence my interest in a tool of the type we're discussing.

IMHO it's about choice. there are lots of options available when it
makes sense to have a separate set of generated objects. many fewer
with start-from-java and no really comprehensive solutions (as yet ;)

> >> ... I can certainly see the benefits to providing a tool that allows
> >> an interactive approach to building a JiBX binding, basically
> >> starting with Betwixt-like defaults and allowing overrides at every
> >> step of the way down to a detailed JiBX binding. The way I envision
> >> it this should show sample XML output (or the current schema, for
> >> those developers able to understand schemas) at every step of the way
> >> - when you change the binding, you immediately get the change
> >> reflected in the schema/sample XML. Ideally you should even be able
> >> to go the other way - modify the schema, and have the binding
> >> automatically reflect the change (or replace the schema with a new
> >> version, and have the binding adjust as best it can and then flag the
> >> mismatches).
> >> ...
> >
> >
> > To clarify the use cases:
> > 1. Schema exists, but no java code

IMHO it's very difficult to support all schema without generation. i'm
not sure it's worth competing with dedicate start-from-schema tools. i
would agree that binding towards a given schema would worth doing. due
to the fact that the same logical categorization can be represented by
different schema may make full support very difficult.

> > 2. Java code exists, but no schema
> > 3. Both schema and java exist.
> > How do we map between them, even when there is very little correlation
> > betwen java and schema. Each one is pretty important I think.
> >
> > I see something a bit different then Dennis. (now where is my virtual
> > white board....) On the left pane I would see a structural
> > representation of the schema portions. In the middle is a place to
> > apply "actions" to a chunk of schema. On the right I would see a list
> > of actions. Actions would be "create object," "set property," or even
> > "run this piece of java code (via janino, groovy or the like)".

+1

definitely a fourth generation feature :)

this is similar to the achitecture used by the second (refactored)
betwixt engine. i suspect that JIBX also uses something similar
(though probably uses different terms).  with beans, you reach a stage
where scripting becomes important. (betwixt doesn't do any of that but
the structure's there.) the problem is that for this to be useful
requires good tools.

i didn't see the connection before but this needs to be a core
feature. IMHO this power would need to be pluggable so that a useful
core toolset (probably bean and field centric if we start from what
JIBX and betwixt have now) could be created quickly.

> > Say I have a schema like so:
> >  <xsd:complexType name="book">
> >    <xsd:sequence>
> >      <xsd:element name="author" type="xsd:string"/>
> >      <xsd:element name="title" type="xsd:string"/>
> >    </xsd:sequence>
> >  </xsd:complexType>
> >
> > I'd see this on the left (with the option to view the schema source)
> > + book
> > |- author
> > |- title
> >
> > When I selected book I would see the middle pane pop up with different
> > events like "on start of tag", "on end of tag", or on body. I'd be
> > able to drag in different actions from the right to certain events and
> > customize them. So on book I'd drag in "create object" and specify the
> > "Book" object. On the author element I'd want to do a set property. It
> > would also be intelligent enough create a mapping for a POJO
> > automatically if it can.
> 
> I like that idea a lot!

+1

(on automated bean mappings)

betwixt maps beans adequately (except for fields which is where JIBX
is strong). it also has lots of automatic mapping strategies developed
over a number of years in response to user requirements. it's clear to
me that one universal automatic mapping strategy isn't expressive
enough. it's important that the tool not only supports pluggable
strategies but ships with a good palette. users need to be able to
import their own strategies. i'd like to be able to bind a bean by
grabbing some strategies from a palette, applying them to generate a
basic mapping. this can then be tuned.

it's also important to ship enough standard mappings for common objects. 

(on events)

the basic idea sounds good but i really think that users are going to
need to be able to plug in more specific builders on top. we need to
be able to make it easy for a java developer faced with a POJO to be
able to ignore the details of the events. IMHO fast prototyping by
java developers who are not strong in cool stuff like xml, groovy and
so on is crucial.

but i agree that it seems better to build this in a pluggable fashion
on top of something that exposes more powerful and more basic
features.

> > ...
> >
> >>
> >> Much of the off-list discussion has revolved around the possibility
> >> of building a generic tool of this type, one able to work with
> >> different frameworks. On thinking it over, it seems to me that at
> >> least the general framework of the tool should be reusable - say the
> >> IDE integration and XML/schema display and manipulation. That would
> >> leave the need to write plugins for each binding framework to handle
> >> XML instance and schema generation from a binding and set of classes,
> >> and to handle editing the actual binding definition (in whatever form
> >> that takes - an XML file for Betwixt and JiBX, annotations for JAXB,
> >> etc.).
> >>
> > The version I described above is probably pretty binding toolkit
> > specific :-), but I'm open to anything really.
> >
> > I'm confused aobut how JAXB can be used to handle multiple versions.
> > You can't really annotate a java class for multiple versions afterall.
> 
> That's true, but JAXB could still use a tool like this within its single
> schema limit, while frameworks that support multiple mappings could go
> further.

+1

IMHO this is a JAXB specific limitation

annotations can be easily used within a multiple mapping framework.
the idea is that annotations become just one way of describing a
mapping. the same objects could be mapped by annotations in one
context and use different bindings specified by files in another. you
could also use multiple forms of annotation.

being able to hook into a JAXB implementation would allow
non-compliant mappings (for example, the JiBX ones) to interoperate.

> >> What do people think of this? Anyone want to jump right in and start
> >> putting this together? ;-)
> >
> >
> > I definitely would like to spend some time working on this next week.
> > Although I want to hear more ideas as there are many bright people
> > hanging around...

+1

i'm pretty enthusiastic to code but there have already been many cool
ideas emerged.

if we are going to play about with some bits and pieces codewise, it
might make sense to indicate to everyone else the bits in question.
i'll probably take a look at seeing if i can pull some useful stuff
from betwixt for the automated bean binding. any opinions on ui
technologies?

i am wondering about meta-data. it seems to me that in order to tied
this all together, the meta data describing the bindings is going to
be important. getting this object model right will probably take some
doing...

> > One other possible solution I just thought of is Dozer (maybe this
> > should go in a seperate thread). Dozer (http://dozer.sf.net) could be
> > used to map multiple sets of DTOs which are generated from a schema to
> > a single set of objects. This seems like a lot of work though.
> 
> That's an interesting possibility, especially for making a
> schema-centric framework like XMLBeans more Java-friendly.

interesting :)

- robert

Re: [Axis2] Better Java-XML mapping

[Dennis Sosnoski <dm...@sosnoski.com>]

Dan Diephouse wrote:

> Dennis Sosnoski wrote:
>
>> While we have a number of tools for generating Java object models to 
>> (more or less) match a schema, most of these tools either cannot work 
>> with pre-existing Java classes or can only work with existing classes 
>> using their own built-in correspondences.
>> ...
>
>
> Agreed. I would add that I see that this is a problem with nearly all 
> approaches. Even when parsing the XML by hand, you need to have 
> seperate code for each version unless you're doing transformations. 
> DTOs are generally the same way.
>
> I don't view the DTO layer as necessarily a bad thing. If you're 
> schema and internal API are a lot different (which they often are), it 
> can make translation a lot easier. And it'd still be nice to map 
> multiple schemas to one set of DTOs.

JiBX can actually handle both these cases directly (direct binding to 
business model objects without the use of DTOs, and multiple schemas to 
a single set of objects). The binding definitions effectively serve the 
same purpose as transfer code or XSLT transformations (within limits). 
Of course, this creates the need to maintain the binding definitions - 
hence my interest in a tool of the type we're discussing.

>
>> ... I can certainly see the benefits to providing a tool that allows 
>> an interactive approach to building a JiBX binding, basically 
>> starting with Betwixt-like defaults and allowing overrides at every 
>> step of the way down to a detailed JiBX binding. The way I envision 
>> it this should show sample XML output (or the current schema, for 
>> those developers able to understand schemas) at every step of the way 
>> - when you change the binding, you immediately get the change 
>> reflected in the schema/sample XML. Ideally you should even be able 
>> to go the other way - modify the schema, and have the binding 
>> automatically reflect the change (or replace the schema with a new 
>> version, and have the binding adjust as best it can and then flag the 
>> mismatches).
>> ...
>
>
> To clarify the use cases:
> 1. Schema exists, but no java code
> 2. Java code exists, but no schema
> 3. Both schema and java exist.
> How do we map between them, even when there is very little correlation 
> betwen java and schema. Each one is pretty important I think.
>
> I see something a bit different then Dennis. (now where is my virtual 
> white board....) On the left pane I would see a structural 
> representation of the schema portions. In the middle is a place to 
> apply "actions" to a chunk of schema. On the right I would see a list 
> of actions. Actions would be "create object," "set property," or even 
> "run this piece of java code (via janino, groovy or the like)".
> Say I have a schema like so:
>  <xsd:complexType name="book">
>    <xsd:sequence>
>      <xsd:element name="author" type="xsd:string"/>
>      <xsd:element name="title" type="xsd:string"/>
>    </xsd:sequence>
>  </xsd:complexType>
>
> I'd see this on the left (with the option to view the schema source)
> + book
> |- author
> |- title
>
> When I selected book I would see the middle pane pop up with different 
> events like "on start of tag", "on end of tag", or on body. I'd be 
> able to drag in different actions from the right to certain events and 
> customize them. So on book I'd drag in "create object" and specify the 
> "Book" object. On the author element I'd want to do a set property. It 
> would also be intelligent enough create a mapping for a POJO 
> automatically if it can.

I like that idea a lot!

>
> ...
>
>>
>> Much of the off-list discussion has revolved around the possibility 
>> of building a generic tool of this type, one able to work with 
>> different frameworks. On thinking it over, it seems to me that at 
>> least the general framework of the tool should be reusable - say the 
>> IDE integration and XML/schema display and manipulation. That would 
>> leave the need to write plugins for each binding framework to handle 
>> XML instance and schema generation from a binding and set of classes, 
>> and to handle editing the actual binding definition (in whatever form 
>> that takes - an XML file for Betwixt and JiBX, annotations for JAXB, 
>> etc.).
>>
> The version I described above is probably pretty binding toolkit 
> specific :-), but I'm open to anything really.
>
> I'm confused aobut how JAXB can be used to handle multiple versions. 
> You can't really annotate a java class for multiple versions afterall.

That's true, but JAXB could still use a tool like this within its single 
schema limit, while frameworks that support multiple mappings could go 
further.

>
>> What do people think of this? Anyone want to jump right in and start 
>> putting this together? ;-)
>
>
> I definitely would like to spend some time working on this next week. 
> Although I want to hear more ideas as there are many bright people 
> hanging around...
>
> One other possible solution I just thought of is Dozer (maybe this 
> should go in a seperate thread). Dozer (http://dozer.sf.net) could be 
> used to map multiple sets of DTOs which are generated from a schema to 
> a single set of objects. This seems like a lot of work though.

That's an interesting possibility, especially for making a 
schema-centric framework like XMLBeans more Java-friendly.

  - Dennis

Re: [Axis2] Better Java-XML mapping

[Dan Diephouse <da...@envoisolutions.com>]

Dennis Sosnoski wrote:

> While we have a number of tools for generating Java object models to 
> (more or less) match a schema, most of these tools either cannot work 
> with pre-existing Java classes or can only work with existing classes 
> using their own built-in correspondences. This limitation makes it 
> very difficult for users to take a start-from-Java approach to 
> developing web services, since the users then have little or no 
> control over the schemas used by the web service (as seen with the 
> JAX-RPC 1.0-style doc/lit mapping). It also makes it very difficult 
> for users to work with evolving schemas, since their data model will 
> need to be regenerated every time the schema changes. Because of this, 
> users often end up writing a translation layer into their applications 
> to take the data from the schema-centric model and convert it into 
> structures actually used by their main application code.

Agreed. I would add that I see that this is a problem with nearly all 
approaches. Even when parsing the XML by hand, you need to have seperate 
code for each version unless you're doing transformations. DTOs are 
generally the same way.

I don't view the DTO layer as necessarily a bad thing. If you're schema 
and internal API are a lot different (which they often are), it can make 
translation a lot easier. And it'd still be nice to map multiple schemas 
to one set of DTOs.

> There are some libraries which provide more flexible conversions 
> between Java and XML, including Betwixt as well as my own JiBX 
> framework. JAXB 2.0 is also taking steps in this direction. The 
> subject of the email exchanges has been the desirability of better GUI 
> tools for working with frameworks which support such flexible 
> conversions.
>
> Betwixt seems to offer very good support for starting from basics and 
> refining the mapping as you go. It basically offers defaults for 
> everything, then lets you override the defaults. JiBX takes almost the 
> opposite approach, requiring the user to specify everything (though 
> there is a tool which will generate a default binding automatically, 
> with a variety of overrides). I can certainly see the benefits to 
> providing a tool that allows an interactive approach to building a 
> JiBX binding, basically starting with Betwixt-like defaults and 
> allowing overrides at every step of the way down to a detailed JiBX 
> binding. The way I envision it this should show sample XML output (or 
> the current schema, for those developers able to understand schemas) 
> at every step of the way - when you change the binding, you 
> immediately get the change reflected in the schema/sample XML. Ideally 
> you should even be able to go the other way - modify the schema, and 
> have the binding automatically reflect the change (or replace the 
> schema with a new version, and have the binding adjust as best it can 
> and then flag the mismatches). I've been adding hooks to JiBX for some 
> time with the intent of moving it in this direction.

To clarify the use cases:
1. Schema exists, but no java code
2. Java code exists, but no schema
3. Both schema and java exist.
How do we map between them, even when there is very little correlation 
betwen java and schema. Each one is pretty important I think.

I see something a bit different then Dennis. (now where is my virtual 
white board....) On the left pane I would see a structural 
representation of the schema portions. In the middle is a place to apply 
"actions" to a chunk of schema. On the right I would see a list of 
actions. Actions would be "create object," "set property," or even "run 
this piece of java code (via janino, groovy or the like)". 

Say I have a schema like so:
  <xsd:complexType name="book">
    <xsd:sequence>
      <xsd:element name="author" type="xsd:string"/>
      <xsd:element name="title" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>

I'd see this on the left (with the option to view the schema source)
+ book
|- author
|- title

When I selected book I would see the middle pane pop up with different 
events like "on start of tag", "on end of tag", or on body. I'd be able 
to drag in different actions from the right to certain events and 
customize them. So on book I'd drag in "create object" and specify the 
"Book" object. On the author element I'd want to do a set property. It 
would also be intelligent enough create a mapping for a POJO 
automatically if it can.

The left pane could be a schema editor as well of sorts. In addition to 
or alternatively, the left pane could show a sample of the XML like 
Dennis mentioned. And if you're missing the java code there could be a 
button which generates a standard mapping.

You could do a ton of cool things if you make this IDE specific. For 
instance if you could tie into the refactoring capabilities of Eclipse 
or IDEA and have it update schema/java mapping automatically.

>
> Much of the off-list discussion has revolved around the possibility of 
> building a generic tool of this type, one able to work with different 
> frameworks. On thinking it over, it seems to me that at least the 
> general framework of the tool should be reusable - say the IDE 
> integration and XML/schema display and manipulation. That would leave 
> the need to write plugins for each binding framework to handle XML 
> instance and schema generation from a binding and set of classes, and 
> to handle editing the actual binding definition (in whatever form that 
> takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
>
The version I described above is probably pretty binding toolkit 
specific :-), but I'm open to anything really.

I'm confused aobut how JAXB can be used to handle multiple versions. You 
can't really annotate a java class for multiple versions afterall.

> What do people think of this? Anyone want to jump right in and start 
> putting this together? ;-)

I definitely would like to spend some time working on this next week. 
Although I want to hear more ideas as there are many bright people 
hanging around...

One other possible solution I just thought of is Dozer (maybe this 
should go in a seperate thread). Dozer (http://dozer.sf.net) could be 
used to map multiple sets of DTOs which are generated from a schema to a 
single set of objects. This seems like a lot of work though.

- Dan

-- 
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com