XML Schema and the SOA Data Model - Java SOA - page 92

//... getters and setters omitted
}
The output of running schemagen this time is a single file shown in Example 2-19 .
Example2-19.Schema file generated using JAXB annotations
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0"
targetNamespace="com.soacookbook.ch02.schemagen"
xmlns:tns="com.soacookbook.ch02.schemagen"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Product2" type="tns:productAnnotated"/>
<xs:complexType name="productAnnotated">
<xs:sequence>
<xs:element name="VERSION"
type="xs:string" default="1.0" minOccurs="0"/>
<xs:element name="mfrDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="name"
type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Let's take a moment to see how each of the annotations contributed to the creation of this
schema. First, the XMLRootElement annotation defined the namespace for the root element.
But that's not actually enough to get the namespace declared across the complex type, as that
annotation applies only to the root element. So you must repeat that namespace in the XMLType
annotation in order to tell schemagen that both the element and the complex type are in the
same namespace. This results in the single file that you see here. Had you left off the XMLType
annotation, schemagen would have made a conservative guess and left the complex type with
no namespace. It then would have been forced to put it in a separate schema file and import
the type into the schema defining the element.
Notice that using the XMLElement field-level modifier you get to retain your static field in the
schema definition. But you're just overriding the fact that it would have been ignored; there is
no concept of “static” in schema you can retain.
Using SchemaOutputResolver
The second way to create a schema based on a Java class is not to use the command-line tool,
but rather to write Java code that does it for you. This has the advantage of being usable at