xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Maring <bambool...@yahoo.com>
Subject design feature requests
Date Thu, 07 Aug 2003 13:41:04 GMT
Hi all,
I've had some experience with JAXB, Castor, and JiBX.  I looked at BEA's XMLBeans briefly,
but my initial analysis scared me away.  1)  because it had a vendor name associated with
it   2)  the generated JavaBeans had additional code stuck in them.
I really don't know if BEA has ever turned anything OpenSource before, but I must say that
I am quite surprised.  The timing with reference to Geronimo certainly perks an eyebrow.
Based on my experience with data architects, object modelers, marshalling frameworks, and
type mapping in JAX-RPC implementations, I'd like to make the following observations and requests
in hopes that they may be considered as part of the redesign of XMLBeans.
1)  data architects want to be able to specify an XML Schema void of any implementation specific
namespaces (basically only the W3C XML Schema namespace)
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 testcases.
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.
Here is what I would love to see in an (un)marshalling framework:
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 performance
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)
4)  do not require the addition of any non W3C namespaces in the XML Schemas of the user data
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
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!
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
8)  really good user documentation 
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.
I look forward to seeing the source code!
Steve Maring

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
View raw message