xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Maring <bambool...@yahoo.com>
Subject Re: [bea-readme] design feature requests
Date Fri, 08 Aug 2003 08:47:27 GMT
> 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
View raw message