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