Thursday, July 8, 2010

Extending schema with redefine and Java


In this case a system which has an external interface (say a web service exposed to external clients) let us only consider the xsd for this example. Assume that the xsd is imported in a wsdl and used.Internally it needs to maintain an enhanced information model which adds multiple attributes to the provided complex types. The internal information model is not a new one it is just an enhanced model.Any additions or changes to the external xsd will require the changes in the internal xsd as well.

Possible solutions

  1. Use a new xsd for external and internal interfaces copying all attributes. The disadvantage for this approach is the maitainanve of the xsds.Any change requires changes in both the places. The advantage is that the internal and external xsd become disconnected and can be maintained seperately. We do not require the advantage in our case since it would be a maintainance overhead

  2. Import the external xsd and reuse the elements whereever possible by extending them or using them as is. It is not a very clean approach lot of repeated code would result but it would be lesser than option 1.

  3. Redefine the elements enhanced and use it for further processing. Much cleaner approach is expected.

Detailed diffierence between xml schema extend vs redefine elements is explained below:

The external xsd and its sample xml is show below:-

Fig. external xsd

Fig. external sample xml

The external interface conatains an element Request with two elements name and child. The child is a complex type with an element t1. The internal interface needs to enhace the child complex type to add two more elements val1 and val2

While using the extend element the schema and the example xml will look like:-

Fig. internal xsd using extends construct

Fig. internal sample xml

As seen above the extends needs to redefine the parent attribute if the child element is extended. This leads to a very complicated xsd and the reusability of the defined types becomes very limited. This problem can be overcome if redefine construct is used as shown below.

Fig. internal xsd using redefine and extends construct

Fig. sample xml for the above xsd

Tool and API support:

JAX-RPC and redefine

According to the JAX-RPC 1.1 specifications (

The following XML Schema features are not required to be supported and WSDL to Java mapping tools are allowed to reject documents that use them: xsd:redefine, xsd:notation, substitution groups.

The JDeveloper does not generate the proxy for the web service that contains the redefine element.

JAXB 1 and Redefine

The XML Schema redefine construct is not supported by JAXB and if such unsupported construct is included in a schema, an error will be generated when you try to generate Java classes from them with xjc.(ref:-

JAXB 2 and Redefine

XJC for JAXB 2 successfully generates the proxy for the web service

SOAP-UI and redefine

SOAP UI does not support the use of redefine elements. I have raised the following bug

XML SPY and redefine

I am using XML Spy 2008. This successfully generates a sample SOAP message from a WSDL containing the redefine element.

WS-Interoperability Basic Profile 1.1

This element is compliant and does not cause any errors.


The redefine construct does provide a flexible construct for extending the schema definations. The support is limited for the construct and is improving. The redefine schema construct cannot be used with JAX RPC, but is compliant with JAXB 2 so any other web services programming model that uses JAXB 2 like JAX WS or Spring Web Services can be used.


Anonymous said...

Very useful information about support redefine in diffrenent tools and libraries.

Thanks a lot!

Anonymous said...

Great Post! I have spent last two days trying to understand why my SOAPUI, JDeveloper are not working correctly for redefine.