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