Java Reference
In-Depth Information
</jaxb:globalBindings>
</xs:appinfo>
</xs:annotation>
//...rest of schema here
</xs:schema>
Here you specify the
jaxb
prefix for the namespace
http://java.sun.com/xml/ns/jaxb
,
which is required. Then in the
appinfo
section, add your global customizations so that any
dateTime
or
date
type you encounter in the current schema or any schema it reuses will as-
sume your custom type. You can add other annotations here in different scopes, and add your
regular comments in the annotation.
The Java type you want to use as the target is indicated by the name attribute, and the type
in the schema you will convert to that target is specified by the
xmlType
attribute. You also
indicate a
parseMethod
and a
printMethod
as the names of methods in the specified JAXB
class that will be intercepted to substitute with your value during parsing and printing.
NOTE
The values you specify in
parseMethod
and
printMethod
must correspond to the data types
you're targeting. For example, if you were customizing the short binding, you'd use something like
this:
printMethod="javax.xml.bind.DatatypeConverter.printShort"
parseMethod="javax.xml.bind.DatatypeConverter.parseShort"
In the next section, we'll look at how to achieve the same thing in an external file.
Using an External File (schemalet)
It might be preferable to put your binding customization annotations in an external file, and
not in the schema itself. Like so many things, this has advantages and disadvantages. The ad-
vantage is that your schema is not mucked up with Java-specific and JAXB-specific code.
You don't leak your implementation out into an otherwise implementation-agnostic schema
document. Depending on your environment, this could pose a greater or lesser problem. I re-
commend preferring the external file method if you don't have constraints preventing it. It
leaves your schema easier to read and less cluttered, and won't give pause to implementors in
your enterprise using other languages. But the downside to using the external method is that
the customization is bound to the schema only at runtime during parsing, and readers of your
source schema may be entirely unaware of the potentially significant changes you might be
