XMLBeans and JAXB

Question

Can someone from BEA explain the relationship and/or differences between the proposed
Java standard API for XML binding, JAXB, and XMLBeans? Obviously XMLBeans offers
additional APIs, such as cursors and XQuery support (which is neat), but it seems
to be non-standard and BEA-specific.
In this context, are there any clear statements from BEA product marketing how
the technology will be productized? Without that, it seems a bit dangerous to
use...
Thanks,
PM

Answer 1

XMLBeans and JAX-B are complementary technologies. JAX-B is a good technology
for loading XML documents into Java objects – in constructing XMLBeans, we have
attempted to be compatible with JAX-B naming conventions. However, JAX-B cannot
necessarily preserve the full fidelity of XML documents, nor does it support 100%
of schema. This is where XMLBeans is complementary - document preservation and
support for extensibility are explicit goals of XMLBeans. Though JAX-B does not
make this possible today, it is conceivable that XMLBeans will be an implementation
of a future JAX-B spec as both technologies may converge together.
Given the above statement, one may ask then why is that preserving full fidelity
of the original XML document may be important? Consider the following advantages:
(1) Sequencing and interleaving information is not lost in XMLBeans. There are
schemas where you care whether <input> comes before <output> or <buy> comes before
<sell> or the other way around. If you just give people a Java .getBuy() and
a .getSell(), they've lost the ability to tell which came first. In XMLBeans,
after the .get you always have the ability to grab an XML cursor on the <buy>
and another one on the <sell> and ask which one came first.
(2) Information that comes into wildcards are not lost in XMLBeans. Consider
the regularly used <xsd:any> and <xsd:anyAttribute> features of schema that allow
any data to appear in the document. With JAX-B, for example, the specification
does not specify how an implementation handle content that it does not know how
to map to a Java representation. But with XMLBeans, you can see where and how
your document has been extended at the wildcards, and change or manipulate the
wildcarded data. Furthermore, something cool is that if you have compiled schemas
for the wildcarded data you can even coerce the wildcards to strongly-typed XMLBeans
and keep on drilling in conveniently. A common use case for this is processing
WSDLs: the w3c schema for WSDL uses wildcards for nearly every interesting piece
of data in a WSDL.
(3) Loading, modifying, and saving an XML document using XMLBeans, you won't lose
all the "other stuff" that human beings don't want to lose on human-readable XML
files, namely comments and all that extra pretty white space between things.
(Unless you want to lose it; XMLBeans can be put in a mode where it is used to
strip extra white space too.)
(4) The architecture is set up so that 100% of schema types can correspond one-to-one
with a Java type. This is perhaps a subtle benefit, but it is powerful because
it means that there are "no regrets" and "no dead-ends" later. You never run
into a schema type that can't be subclassed because of Java problems, or some
extension that has some data that can't be accessed from Java.
I hope this helps shed some light on the complementary relationship between XMLBeans
and JAX-B.
Regards,
Samir
"Peter Meyer" <[email protected]> wrote:
>
Can someone from BEA explain the relationship and/or differences between
the proposed
Java standard API for XML binding, JAXB, and XMLBeans? Obviously XMLBeans
offers
additional APIs, such as cursors and XQuery support (which is neat),
but it seems
to be non-standard and BEA-specific.
In this context, are there any clear statements from BEA product marketing
how
the technology will be productized? Without that, it seems a bit dangerous
to
use...
Thanks,
PM