[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    Re: design feature requests
From:       "David Bau" <david.bau () bea ! com>
Date:       2003-08-08 19:44:50
[Download RAW message or body]

> 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


[prev in list] [next in list] [prev in thread] [next in thread]