> I believe the case discussed here is using the same JAXB-generated
bean more than once in the object graph.
yes, that's where my XML has trouble :)
The file format I'm working with allows you to define named groups of
files so you can effectively write
<ASSOCIATE>
<GROUP>one<GROUP>
<FILES>
<FILE path="x1x">
... additional file information ...
</FILE>
<FILE path="x2x">
... additional file information ...
</FILE>
</FILES>
</ASSOCIATE>
The file format allows two ways of expressing the same associations ie
<ASSOCIATE>
<GROUP>one<GROUP>
<GROUP>two<GROUP>
<FILES>
<FILE path="1">...</FILE>
</FILES>
</ASSOCIATE>
or equivalently
<ASSOCIATE>
<GROUP>one<GROUP>
<FILES>
<FILE path="1">...</FILE>
</FILES>
</ASSOCIATE>
<ASSOCIATE>
<GROUP>two<GROUP>
<FILES>
<FILE path="1">...</FILE>
</FILES>
</ASSOCIATE>
My program can normalize these or not normalize these associations
depending on the users preference. This maybe isn't the most motivating
example, but the schema (DTD) was designed many years ago and that is
probably not that uncommon a situation (?)
The problem is then that when constructing the non-normalized form the
routines are currently written to just pick up chunks of object tree and
move them around without ever being aware of what the object tree
represents. So, at the moment, we can get away without ever having a
separate data structure for a FILE object - rather we can use the xjc
generated classes without change.
I was thinking that an object /tree/ with a cycle could never marshal to
valid XML, but an object tree (or object DAG) could marshal to valid XML
without problems? I can see whether this is a good thing to allow being
arguable in both directions, but doing the check in Validator implies
that the object dag doesn't represent valid XML when it does? or is that
also arguable? :)
thanks,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net