+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:[EMAIL PROTECTED] > Sent: Friday, August 19, 2005 10:25 AM > To: [email protected] > 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 > > [EMAIL PROTECTED] wrote: > > >here is my +1 > >Chathura > > > > > > > >>+1, > >>welcome Dennis :-) > >> > >>- Ruchith > >> > >>On 8/19/05, Davanum Srinivas <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
