You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by David Bau <da...@bea.com> on 2003/08/08 02:45:51 UTC
Re: [bea-readme] design feature requests
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
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.
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)
Yes.
> 2) the (un)marshalling framework should use an XML pull model for
performance
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
java.util.HashMap?
> 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
vice-versa.
> 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
[http://workshop.bea.com/xmlbeans/XsdUpload2.jsp?ACCEPT=checked]
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/
Re: design feature requests
Posted by David Bau <da...@bea.com>.
> a set of classes to represent the data in the DDL. The XML Schemas, the
> DDL, and the Java classes get officially blessed. I now no longer care
> about source code generation. I just have to come up with an
> (un)marshalling framework to map between an existing set of schemas and
> Java classes.
Good scenario.
How do you think the mapping should be done between the existing schemas
and Java classes? What are folks' feelings about the binding config files
that
we have in existing solutions and existing standards? It's always seemed
painful to me to have three parallel artifacts (java, schema, binding
config).
Or perhaps that's just the reality of the problem we face.
> element ordering should be controlled by the binding/mapping file.
> I can see how comments are problematic, but I don't think I would
> consider them real data from an application perspective.
> I'll be if we ignore them they will go away! lol
Element ordering in XML is not a matter of static configuration or
just schema, but of instance data. Consider the following type
(a fairly typical form):
<xs:complexType name="example">
<xs:all>
<xs:element name="buyAt" type="xs:decimal"/>
<xs:element name="sellAt" type="xs:decimal"/>
</xs:all>
</xs:complexType>
The most natural binding to Java is
class Example
{
BigDecimal getBuyAt()...
BigDecimal getSellAt()...
}
An instance could be loaded that says either
<buyAt>1.00</buyAt><sellAt>2.00</sellAt>
or
<sellAt>2.00</sellAt><buyAt>1.00</buyAt>.
But then if you had the most obvious implementation of that Java
class, you would have lost the information about whether <buy/>
preceded <sell/> or vice-versa. It might be important, if you need
to distinguish an investor from a short-seller. Or the order might
not be important for your app.
Also common is the case where the <xs:all> is replaced by
<xs:choice minOccurs="0" maxOccurs="unbounded">
Here, there's not one bit of ordering information, but a whole
permutation. What to do? Sometimes the order is important
to the app. Often it's not. Currently, XMLBeans provides a
solution here that provides both views in a natural way, no
configuration needed, but that is also the reason that the generated
JavaBeans aren't just "ordinary" classes. On the surface (on their
interface) they look like plain-old JavaBeans, but behind the
scenes (in their implementation) they maintain the full XML
infoset.
> I should get a chance to look it over next week.
Cool.
Cheers,
David
- ---------------------------------------------------------------------
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/
Re: design feature requests
Posted by David Bau <da...@bea.com>.
> a set of classes to represent the data in the DDL. The XML Schemas, the
> DDL, and the Java classes get officially blessed. I now no longer care
> about source code generation. I just have to come up with an
> (un)marshalling framework to map between an existing set of schemas and
> Java classes.
Good scenario.
How do you think the mapping should be done between the existing schemas
and Java classes? What are folks' feelings about the binding config files
that
we have in existing solutions and existing standards? It's always seemed
painful to me to have three parallel artifacts (java, schema, binding
config).
Or perhaps that's just the reality of the problem we face.
> element ordering should be controlled by the binding/mapping file.
> I can see how comments are problematic, but I don't think I would
> consider them real data from an application perspective.
> I'll be if we ignore them they will go away! lol
Element ordering in XML is not a matter of static configuration or
just schema, but of instance data. Consider the following type
(a fairly typical form):
<xs:complexType name="example">
<xs:all>
<xs:element name="buyAt" type="xs:decimal"/>
<xs:element name="sellAt" type="xs:decimal"/>
</xs:all>
</xs:complexType>
The most natural binding to Java is
class Example
{
BigDecimal getBuyAt()...
BigDecimal getSellAt()...
}
An instance could be loaded that says either
<buyAt>1.00</buyAt><sellAt>2.00</sellAt>
or
<sellAt>2.00</sellAt><buyAt>1.00</buyAt>.
But then if you had the most obvious implementation of that Java
class, you would have lost the information about whether <buy/>
preceded <sell/> or vice-versa. It might be important, if you need
to distinguish an investor from a short-seller. Or the order might
not be important for your app.
Also common is the case where the <xs:all> is replaced by
<xs:choice minOccurs="0" maxOccurs="unbounded">
Here, there's not one bit of ordering information, but a whole
permutation. What to do? Sometimes the order is important
to the app. Often it's not. Currently, XMLBeans provides a
solution here that provides both views in a natural way, no
configuration needed, but that is also the reason that the generated
JavaBeans aren't just "ordinary" classes. On the surface (on their
interface) they look like plain-old JavaBeans, but behind the
scenes (in their implementation) they maintain the full XML
infoset.
> I should get a chance to look it over next week.
Cool.
Cheers,
David
- ---------------------------------------------------------------------
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/
Re: [bea-readme] design feature requests
Posted by robert burrell donkin <rd...@apache.org>.
On Friday, August 8, 2003, at 09:47 AM, Steve Maring wrote:
<snip>
> > "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.
>
> Well then maybe it should be a configurable option, set in the binding/
> mapping file, for source code generation and mapping purposes. I can
> imagine a use case where my XML Schemas and subsequent Java data types
> are branded "The Enterprise Model". If my Java data types are not
> simple JavaBeans, then my junior developers trying to code web services
> are always going to have to plug in the (un)marshalling framework into
> the web services implementation (currently non-trivial in most cases).
> This because the default BeanSerializer EXPECTS that any non-primitive
> Java data types coming along are in fact REAL JavaBeans with public
> default constructors!
one possible design would be to use a real java bean (or at least an
object ;) to specify the mapping (rather than a file).
one implementation might configure itself from an input source but other
implementations could be generated from an input source. users could even
create their own subclasses.
- robert
- ---------------------------------------------------------------------
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/
Re: [bea-readme] design feature requests
Posted by robert burrell donkin <rd...@apache.org>.
On Friday, August 8, 2003, at 09:47 AM, Steve Maring wrote:
<snip>
> > "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.
>
> Well then maybe it should be a configurable option, set in the binding/
> mapping file, for source code generation and mapping purposes. I can
> imagine a use case where my XML Schemas and subsequent Java data types
> are branded "The Enterprise Model". If my Java data types are not
> simple JavaBeans, then my junior developers trying to code web services
> are always going to have to plug in the (un)marshalling framework into
> the web services implementation (currently non-trivial in most cases).
> This because the default BeanSerializer EXPECTS that any non-primitive
> Java data types coming along are in fact REAL JavaBeans with public
> default constructors!
one possible design would be to use a real java bean (or at least an
object ;) to specify the mapping (rather than a file).
one implementation might configure itself from an input source but other
implementations could be generated from an input source. users could even
create their own subclasses.
- robert
- ---------------------------------------------------------------------
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/
Re: [bea-readme] design feature requests
Posted by Steve Maring <ba...@yahoo.com>.
> XMLBeans current sweet spot is the "start from XML Schema" use case.
I never actually tried the "start from Java" senario! Interesting.
> 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.
looks like more good stuff
> "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.
Well then maybe it should be a configurable option, set in the binding/
mapping file, for source code generation and mapping purposes. I can
imagine a use case where my XML Schemas and subsequent Java data types
are branded "The Enterprise Model". If my Java data types are not
simple JavaBeans, then my junior developers trying to code web services
are always going to have to plug in the (un)marshalling framework into
the web services implementation (currently non-trivial in most cases).
This because the default BeanSerializer EXPECTS that any non-primitive
Java data types coming along are in fact REAL JavaBeans with public
default constructors!
Are you saying that the complex relation between XML Schema and Java
cannot be fully represented in a binding/mapping file?
> 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 java.util.HashMap?
yep, that's a nasty one. Since I'm new to the "start from Java" senario,
I'll have to look around a bit. Perhaps Castor has a usable approach
to this.
> 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 vice-versa.
Well, yes. However, let me add another conceivable use case to show
what I'm getting at. Let's say my data architect hands me a DDL and
a set of XML Schemas to go along with it. I can create a mapping
between these with Hibernate and I'm good to go in the persistance layer.
Then the data architect hands the DDL to my designer to come up with
a set of classes to represent the data in the DDL. The XML Schemas, the
DDL, and the Java classes get officially blessed. I now no longer care
about source code generation. I just have to come up with an
(un)marshalling framework to map between an existing set of schemas and
Java classes.
> 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.
element ordering should be controlled by the binding/mapping file.
I can see how comments are problematic, but I don't think I would
consider them real data from an application perspective.
I'll be if we ignore them they will go away! lol
> You can get it already under an open source license, although it's only
> currently posted on bea.com [http://workshop.bea.com/xmlbeans/XsdUpload2.jsp?ACCEPT=checked]
I should get a chance to look it over next week. Congrats on being able
to turn something OpenSource that comes out of a corporate monolith. It's
generally hard enough to convince corporate execs that using OpenSource is
OK, let alone turning there own IP over to it! Cheers on that.
-Steve Maring
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: [bea-readme] design feature requests
Posted by Steve Maring <ba...@yahoo.com>.
> XMLBeans current sweet spot is the "start from XML Schema" use case.
I never actually tried the "start from Java" senario! Interesting.
> 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.
looks like more good stuff
> "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.
Well then maybe it should be a configurable option, set in the binding/
mapping file, for source code generation and mapping purposes. I can
imagine a use case where my XML Schemas and subsequent Java data types
are branded "The Enterprise Model". If my Java data types are not
simple JavaBeans, then my junior developers trying to code web services
are always going to have to plug in the (un)marshalling framework into
the web services implementation (currently non-trivial in most cases).
This because the default BeanSerializer EXPECTS that any non-primitive
Java data types coming along are in fact REAL JavaBeans with public
default constructors!
Are you saying that the complex relation between XML Schema and Java
cannot be fully represented in a binding/mapping file?
> 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 java.util.HashMap?
yep, that's a nasty one. Since I'm new to the "start from Java" senario,
I'll have to look around a bit. Perhaps Castor has a usable approach
to this.
> 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 vice-versa.
Well, yes. However, let me add another conceivable use case to show
what I'm getting at. Let's say my data architect hands me a DDL and
a set of XML Schemas to go along with it. I can create a mapping
between these with Hibernate and I'm good to go in the persistance layer.
Then the data architect hands the DDL to my designer to come up with
a set of classes to represent the data in the DDL. The XML Schemas, the
DDL, and the Java classes get officially blessed. I now no longer care
about source code generation. I just have to come up with an
(un)marshalling framework to map between an existing set of schemas and
Java classes.
> 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.
element ordering should be controlled by the binding/mapping file.
I can see how comments are problematic, but I don't think I would
consider them real data from an application perspective.
I'll be if we ignore them they will go away! lol
> You can get it already under an open source license, although it's only
> currently posted on bea.com [http://workshop.bea.com/xmlbeans/XsdUpload2.jsp?ACCEPT=checked]
I should get a chance to look it over next week. Congrats on being able
to turn something OpenSource that comes out of a corporate monolith. It's
generally hard enough to convince corporate execs that using OpenSource is
OK, let alone turning there own IP over to it! Cheers on that.
-Steve Maring
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software