xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: Start-with-java annotations
Date Wed, 19 Nov 2003 21:40:20 GMT

On 19 Nov 2003, at 12:35, David Bau wrote:

> Robert writes (on comparison to Castor):
>
>> maybe point 2 needs a little expansion: serialization must be
> essentially lose-less in a java sense. i'd say that object round
> tripping means being able to go from a symantically meaningful object
> graph to an (easily) human readable (and symantically meaningful) xml
> document and then back to an object graph which is equivalent to the
> original.
>
> I agree with the point - "serialization" isn't what we're after but 
> just
> "round tripping to XML".  Maybe we should call it "marshalling" 
> instead of
> serialization.  But I'm still interested in the details the distinction
> you're drawing. If true serialization is loss-less, then the 
> implication is
> that marshalling is allowed to lose something.

i think that serialization is field based. one of the weaknesses of 
castor is that it's field-oriented. most OOP developers are more used 
to think about methods than fields. (AFAIK) castor actually works on 
the basis of methods but the terminology and design is field-oriented.

a good java <-> xml serializer would (in my view) provide lose less 
serialization of an object's fields. in other words, equal values for 
each field. a good java <-> xml round trip mapper would provide 
equivalent objects. in some cases, loss of accuracy may be an 
acceptable tradeoff for nicer xml.

for example, think about a java.util.Date birthday property which is 
backed by a java.util.Date field. a good serializer would serialize the 
field and would record the value of that field to sufficient accuracy 
to recreate an equal java.util.Date object.

<birthday>1st Apr 1672 03:00:00.120 GMT</birthday>

what a good mapper would do is to allow the developer to flavour the 
mapping with symantic meaning. in this case, the property represents a 
day (even though the data-type is date-time). so, a good mapper may 
produce more like:

<birthday>16720401</birthday>

when this comes to be round tripped, since the time information has 
been thrown after, this is a lossy mapping. but the mapping loses no 
symantically meaningful information and produces better xml.

> What kinds of things should fall into the gap?
>
> For example:
>   - How should we pick which parts of your classes go out to xml?
>   - What about non-tree data graphs?  Non-acyclic ones?
>   - Are there other things?

i suppose this is the big question about mapping :)

> Maybe the gap should be programmer-defined.

i think that this is the way forward. it takes more than just the code 
to create a good mapping.

> JAX-RPC definitely provides a
> standard with some "default" rules for how these things "should" work 
> (in
> start-from-java), but there's also definitely a lot of Java classes 
> which
> cannot be represented as XML using JAX-RPC default rules.
>
> Feels to me that there are two Q's that should be answered to 
> understand the
> start-from-java problem:
>
> 1. To what extent do we need to be able to marshall all different 
> kinds of
> Java in the start-from-java case, particularly those which aren't 
> covered by
> JAX-RPC "default" rules?  For example, perhaps we should permit you to
> marshal to/from fields rather than just public properties, if you 
> annotate
> the fields in a certain way...?

my experience is that mapping properties is much more useful but more 
difficult. in the end, you'll probably end up supporting both but 
properties are (IMHO) the key. for example, with betwixt, there have 
been numerous requests for property-related features but only one time 
that using fields has been requested.

mapping field is easier than properties but does have some wrinkles and 
these wrinkles seem to be hard to solve. java 1.4 does a good job of 
field-based serialization and contains numerous special cases for base 
java classes (which would otherwise be very hard to map). i'd suggest 
that those people who are principally interested in field-based 
serialization would be better advised to use that.

> 2. To what extent do we need to be able to generate all different 
> kinds of
> schema in the start-from-java case?  For example, perhaps you should 
> be able
> to specify that a specific property marshals to a specific XML element 
> name,
> or perhaps to an XML attribute instead of an element?

a good question. your example is just the tip of the iceberg.

- 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/


Mime
View raw message