xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <david....@bea.com>
Subject Re: [bea-readme] design feature requests
Date Fri, 08 Aug 2003 00:45:51 GMT
Hi Steve,

> The timing with reference to Geronimo certainly perks an eyebrow.

Geronimo is certainly interesting to me too.  But came as a complete suprise
to me, and the Apache XMLBeans work is completely unrelated to it.  Maybe
I'm not plugged in enough.

On your real questions: XMLBeans currently is not designed as a Castor
replacement.  Castor's sweet spot is the "start from Java" use case, and
XMLBeans current sweet spot is the "start from XML Schema" use case.

Filling Castor's role is an interesting problem, but it's not something that
the dev team has committed to investing in yet. Your questions are the kinds
of things we'd have to understand if we wanted to do this, so it's a good
discussion to understand.  With that in mind, my comments below:

> 1)  data architects want to be able to specify an XML Schema void of any
implementation specific namespaces (basically only the W3C XML Schema
> 2)  object modellers want simple JavaBeans that implement
java.io.Serializable, have a public default constructor, and do not import
anything outside the scope of the JDK.
> 3)  programmers want a single ubiquitous (un)marshalling framework that
they can use across the whole J2EE enterprise, web services, and client

Agreed, those are good goals. In the XMLBeans world, we are very
data-oriented, and we add a few others:

4) Data architects want to be able to rely on using all of the XML Schema
spec, instead of probing around for a "safe" subset.
5) When instances of XML go through the system, the whole infoset should be
available.  For example, XML is specifically designed to permit
extensibility attributes and elements; if you lose these, you lose much of
the robustness of XML to evolution and change.
6) Loading and saving XML with only minor mods should result in the
identical document with minor mods.  Although throwing away things like XML
comments may seem OK, in doing this sort of thing you lose a core reason to
use XML, which is its human-readability.

> I personally feel that these should be the three core requirements of an
(un)marshalling framework and should be met at all cost.  I've currently
only found this capability by using Castor and writing a set of JAX-RPC
Castor Serializers for Apache Axis.  However, Castor is not completely an
ideal implementation at this point, and the development effort on it appears
to have weened a bit.

"At all cost" is a stronger statement than we make.  The constructor
requirement you propose in particular is attractive, yet fairly
constraining, because of the penalties you need to accept.  By tying
yourself to a single public implementation class, you rule out (1) allowing
a framework to provide multiple different implementations (e.g., fast versus
high-fidelity versus change-tracking); you rule out (2) allowing
sophisticated users to wrap your classes with their own implementations; and
you rule out (3) use of other powerful techniques like dynamic proxies as
interceptors.  I agree it would be desirable to say "new Foo()", but
"Foo.Factory.newInstance()" is not too bad, and the difference in
convenience needs to be weighed against the other penalties.

> 1)  the binding and mapping specification should be one and the same;
i.e. I should be able to source generate my JavaBeans from an XSD with the
default mapping and subsequently (un)marshal without specifying a mapping;
I should also be able to create custom bindings/mappings in a single file
that can be used to source generate and (un)marshal  (Castor requires a
seperate file for binding and mapping, but they almost look identical)


> 2)  the (un)marshalling framework should use an XML pull model for

It should use whatever model is fastest.  Agreed, pull can be very very
fast, but the main advantage of pull is architectural modularity.  It can't
hurt for unmarshalling to support both pull and push, and internally default
to whatever is fastest.

> 3)  the framework should have it's own type mapping registry that is
initialized by either the default mapping or a custom binding/mapping file;
this should significantly increase performance (this is why Castor is slower
than some of the other frameworks)

Yes, initialization must be fast.  Throughput is even more important.

> 4)  do not require the addition of any non W3C namespaces in the XML
Schemas of the user data types

XMLBeans certainly is free of any nonbuiltin namespaces, since it's "start
from schema".  We use just the schema you give us.  However, I'm curious
what your proposed approach should be for java.util collection classes and
so on when you're doing "start from java"?  What should you do with

> 5)  do not source code generate or do byte code modifications to the user
JavaBeans in such a way as to couple them to the (un)marshalling framework
by requiring the import of (un)marshalling framework specific classes

If you "start from Java" the binding compiler should keep its "hands off the
Java".  If you "start from schema" you need to keep your "hands off the
schema".  The two scenarios are fairly different, and currently if you start
from Java, most binding frameworks require generation of schema, and also

> 6)  the source code generated JavaBeans should be REAL JavaBeans with
public default constructors, and not some elaborate abstraction framework
with factories for instantiation (JAXB has issues here).  They are stupid
structs for Pete's sake!

Again, this is an important goal for "start from java".  In "start from xml
schema", you want your generated objects to correspond to elements in the
XML tree - they're just stupid xml elements for pete's sake... why would you
ever want to drop element ordering information when you load XML?  XML trees
are simple, but they are element-ordered and mixed with and comments and
text, and so slightly different from the Java data model.

> 7)  the source code of the (un)marshalling framework should come with a
JAX-RPC XMLBeansSerializer, XMLBeansDeserialzier, XMLBeansSerializerFactory,
and XMLBeansDeserializerFactory that either directly implements the JAX-RPC
serialziation framework interfaces of implements those of individual JAX-RPC
implementations that offer significant value-add (Apache Axis for example);
these should be configurable to use user specified custom mapping file

Agreed.  JAXRPC doesn't do a great job at standardizing serializers and
deserializers.  Developers around here are interested in making sure we plug
into a few of the proprietary ones, including Axis and others.

> 8)  really good user documentation

Of course.  Want to help?

> I'd love to see this effort implement the JAXB specification, but only in
so far that doing so does not deviate from the three golden requirements
that I noted in my OBSERVATIONS.  The JAXB spec currently has some problems
and needs a bit of massaging to allow for seemless integration into the
JAX-RPC spec.

All points taken seriously.

> I look forward to seeing the source code!

You can get it already under an open source license, although it's only
currently posted on bea.com

Stay tuned for source code here on cvs shortly.

Looking forward to working with you and others here,

David Bau

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

View raw message