Have to admit it is not clear for me why since in any case the models differ and JAXB supports everything in both cases. Ack it is not the same impl but one is not really harder than the other since it is pure model mapping there. If you want the consolidated model you have to use maven whatever you do so from my window and from the several hacks I did on tooling in that area this doesn't look accurate at all, just a fear to change whate exists but will be mandatory anyway.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 3 avr. 2026 à 10:33, Martin Desruisseaux via dev < [email protected]> a écrit : > To follow up on technical remarks by Chris below, Eliott and some others > explaining why they prefer B, I wonder: is it clears to all peoples > voting for A that this approach increases the difficulty of using > standard XML tools? At least with JAXB, it makes the use of XSLT > practically mandatory for no technical benefit that I can see. I don't > want to start a new debate (this email is not an attempt to convince > anyone), I'm just afraid that there is a temptation to vote for A on the > basis of a principle (the idea that it is good to increase version > number), and hope that the implications on XML tools were not > underestimated. > > Cheers, > > Martin > > Le 02/04/2026 à 22:36, Chris Lafren a écrit : > > > I just subscribed to the list to participate in this vote. I hope that's > okay. > > > > I prefer option B. > > > > I've been using XML technologies for more than 20 years. > > From a purely XML perspective, option A is a very bad idea. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
