On Mon, 2013-07-22 at 14:16 -0500, jzh...@ximpleware.com wrote: > I think vtd-xml is quite comparable to xml bean,...
Looking at the vtd-xml web site on sourceforge, I am struggling to see much similarity with XMLBeans beyond the superficial one that they both operate on XML-format data. From my point of view the most significant difference is that XMLBeans generates a domain-specific API from XML Schemata, which is done before any XML data can be processed. vtd-xml presents a generic API to parse and index XML data directly, without reference to any user/developer-written external entities that define the structure of the XML data. Put another way, XMLBeans is all about data integrity, strong and static typing, validation against external domain-specific data definitions, and access paths to data that are derived from those external definitions. vtd-xml is all about efficiency and optimising generic access to XML data. Another difference is that in order to distribute applications using vtd-xml under a non-GPL licence you have to get a commercial licence from XimpleWare. XMLBeans is distributed under the Apache licence which is much more permissive. > > > ----- Original Message ----- > From: > user@xmlbeans.apache.org > > To: > <user@xmlbeans.apache.org> > Cc: > > Sent: > Mon, 22 Jul 2013 13:46:37 -0400 > Subject: > Re: Project still maintained? > > > This is awfully unfortunate. To my knowledge, there's no > comparable product out there. We're still struggling with a > few XMLBeans issues that we've had to go to straight DOM to > work around. I was hoping that future releases would address > some of these issues, but it doesn't appear to be the case. Certainly, the reference JAXB implementation doesn't come close, at least when I tried it last. I was bitten badly by the loss of typing when every instance of a subtype of IDREF just became a reference to java.lang.Object. XMLBeans excels in its handling of this kind of thing. The last time I looked around, the closest thing that I found to XMLBeans was EclipseLink MOXy. IIRC one of the MOXy developers pointed out the similarity on this list. Having said that, I fully agree with others on this thread that it is a real pity that XMLBeans has reached this state, and would much prefer to see it remain live and at least maintained, even without development of new features. I don't have a huge amount of time or advanced expertise to contribute right now, ironically this is partly because we are just starting a new project that uses XMLBeans. Porting earlier XMLBeans work to something like MOXy for this project would be a big task. Also, if I understand the situation correctly, it would introduce requirements for Eclipse components at the build stage that use MOXy. These requirements don't exist with XMLBeans: I can build the API+extensions and bundle them up with nothing more than a JDK and Saxon, together with ant or some basic scripting. I am sure that I could find some time to make a few contributions at the coding/debugging level. Like others, I have my pet gripes that I would like to see fixed (such as support for covariant return types that I have to work around in awful hacky ways, and better handling of Extension Interfaces). The timing is very bad for me to even consider taking on a substantial role though. Regards, Peter. -- Peter Keller Tel.: +44 (0)1223 353033 Global Phasing Ltd., Fax.: +44 (0)1223 366889 Sheraton House, Castle Park, Cambridge CB3 0AX United Kingdom --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: user-h...@xmlbeans.apache.org
