In order to go through some exercise here, I recently needed to create a few Java classes from XSD schema. “Well,” I thought, “JAXB with its integrated XJC is your friend!” And so it is, but you might have to dig a little deeper.
The problem I was facing was a schema that had references to WS-Security, XML Encryption and XML Signature. As such, it imported all these schemas from the web using <xsd:import namespace=”…” schemaLocation=”http://…” />. Since xjc is pretty flexible, accessing these schemas on the web was a charm, even through the firewall. After all, this is much better than downloading all the referenced schemas (and all schemas they reference) and edit the imports to point to the right location in the file system.
Well, not so quick. In their infinite wisdom and foresight, the schema developers at OASIS and W3C decided to use different schema locations for XML Dsig. They reference the same schema (with identical namespace, obviously), but import through different schemaLocation URIs. That confuses xjc to no end, since it detects a re-definition of the same object and gives up.
In order to resolve this problem, you can create an XML Catalog, that allows you to rewrite (or redefine) URLs referenced in you schema. Here is an example:
<?xml version=“1.0”?>
<catalog xmlns=“urn:oasis:names:tc:entity:xmlns:xml:catalog”>
<system
systemId=“http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd”
uri=“http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd” />
</catalog>
This simple catalog redefines the URI used by the XML encryption schema to point to the one used by OASIS. The XML Catalog specification provides many more options, and it is good to know that xjc supports this.
While this is quite simple, I found it relatively hard to find concrete examples on how to use this mechanism.
tag: XML Catalog, XML Schema, XSD, JAXB, XJC, Data Binding