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

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.


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

Reply via email to