Question

I am using xjc to generate Java classes from the XML schema and the following is an excerpt of the XSD.

<xs:element name="NameInfo">
  <xs:complexType>
    <xs:sequence>
      <xs:choice>
        <xs:element ref="UnstructuredName"/> <!-- This line -->
        <xs:sequence>
          <xs:element ref="StructuredName"/>
          <xs:element ref="UnstructuredName" minOccurs="0"/> <!-- and this line! -->
        </xs:sequence>
      </xs:choice>
      <xs:element ref="SomethingElse" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

For the most part the generated classes are fine but for the above block I would get something like:

public List<Object> getContent() {
  if (content == null) {
    content = new ArrayList<Object>();
  }
  return this.content;
}

with the following comment above it:

* You are getting this "catch-all" property because of the following reason: 
* The field name "UnstructuredName" is used by two different parts of a schema. See: 
* line XXXX of file:FILE.xsd
* line XXXX of file:FILE.xsd
* To get rid of this property, apply a property customization to one 
* of both of the following declarations to change their names: 
* Gets the value of the content property.

I have placed a comment at the end of the two line in question.

At the moment, I don’t think it will be easy to change the schema since this was decided between vendors and I would not want to go this route (if possible) as it will slow down progress quite a bit.

I searched and have found this page, is the external customization what I want to do? I have been mostly working with the generated classes so I’m not entirely familiar with the process that generates these classes. A simple example of the "property customization" would be great! Alternative method of generating the Java classes would be fine as long as the schema can still be used.

EDIT: I should clarify that the two UnstructuredName are indeed the same element.

Answer 1

The essential problem here is that you have a <xs:sequence> consisting of an <xs:choice>, which translates in Java to “a List of things”. Java’s type structure isn’t flexible enough to represent this any better.

A binding customisation might help you, but in this case, I suspect not, since I can’t see a better way to represent this information.

An alternative technique I’ve used in the past is to pass the schema through a simple XSLT transformation first, re-arranging the components into something more JAXB-friendly, while still permitting the same structures the documents will have in reality. This way, you can “change” the schema without changing the original.