Joe Fialli writes:
> A basic premise in JAXB is to extract semantically meaningful names out of
> an
> XML schema and use them in the Java representation. When the names are
> extracted, they are extracted "as is" except for one exception case that
> I will cover at the end of this comment. It is important to extract them
> as is by default to preserve name uniqueness and thus avoid naming
> collisions
> in the generated Java code. For example, if one had an element foo and
> an element fooList, a name collision would be caused by default binding
> if all repeating occurance elements bound to a List had "List" appended
> as a suffix by default binding. There have been other requests for
> providing a
> global customization to append a suffix to all List properties and this
> request
> has merit and will be considered for the next release. However, by
> default, it
> is better to not perform any unneccessary manipulations on the XML Schema
> names
> that are being mapped to Java.
Good point. I knew there must have been a reason. However, I would still
like to see this become a feature, as I see the appending of List or Array
to method signatures to be the "rule" rather than the "exception". This
unfortunately presents a significant conflict between portability and
intuitive use. I'd like to see what the result of the JAXB body's
consideration will be.
On another reply to my initial email Kohsuke Kawaguchi made the
recommendation of using the following example (utilizing the jaxb:property
addition):
<xsd:element name="bathtubToys">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="rubberDucky" minOccurs="1" maxOccurs="unbounded">
<xsd:annotation><xsd:appinfo>
<jaxb:property name="RubberDuckies"/>
</xsd:appinfo></xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
This will solve my problems, and I sincerely appreciate the answer from
Kohsuke. However, this approach requires the Schema designer to know of
another namespace (jaxb), when initially all they needed to know was XML
Schema v. 1.0 (xsd) - something I consider very convenient and ultimately
portable among platforms. Perhaps in claiming so, I openly admit my
ignorance of the jaxb namespace ;)
> To enable the most generic implementation and to allow for future support
> of
> binding JAXB to existing Java classes, great lengths were taken to not
> impose
> any superclass on all schema derived interfaces.
>
> Requiring the TreeModel interface would have benefitted those who wish to
> generically traverse JAXB data structures as a tree; however, there
> would be a runtime performance overhead and usability issue for those who
> did not wish that a TreeModel exists.
The TreeModel and supporting classes (TreeNode, etc.) are merely interfaces,
not implementations. Although adding TreeModel interfaces (even better yet,
TreeModel interfaces specific to XML without Swing specifics) would slightly
increase memory requirements for processing and instantiation, I feel the
added functionality would far outweigh the added overhead.
JAXB and well-formed XML, at their very conceptual core, are TreeModels of a
data structure. To include "superset" functionality could only further
empower the programmer and enhance acceptance and adoption of the Sun JAXB
implementation.
After all, the programmer already familiar with JAXB implementations would
never even have to know about the added functionality. They could
essentially ignore functionality they don't require.
Again, these are my opinions. I will wait and see what the next release
holds.
Thanks very much for your answers.
Les Hazlewood