Question

I want to create an XSD for one application and another XSD wich extends the first (only by adding elements).

I want the XML file generated by the second application to be valid with the first one.

I tried this:

First XSD:

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns="example"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       targetNamespace="example"
       elementFormDefault="qualified" attributeFormDefault="qualified">

  <xs:complexType name="typeA">
    <xs:sequence>
      <xs:element name="elA" type="xs:string" />
      <xs:any namespace="##any" minOccurs="0" processContents="lax" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="root" type="typeA" />
</xs:schema>

Second XSD:

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns="example"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       targetNamespace="example">
  <xs:redefine schemaLocation="firstXSD.xsd">
    <xs:complexType name="typeA">
      <xs:complexContent>
       <xs:extension base="typeA">
         <xs:sequence>
           <xs:element name="newElement" type="xs:string" />
         </xs:sequence>
       </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:redefine>
</xs:schema>

Example of XML which must be valid with the first XSD (but not the second):

<?xml version="1.0" encoding="UTF-8" ?>
<root xmlns="example">
  <elA>MyString</elA>
</root>

Example of XML which must be valid with both XSD

 <?xml version="1.0" encoding="UTF-8" ?>
<root xmlns="example">
  <elA>MyString</elA>
  <newElement>MyNewString</newElement>
</root>

The previous XSD violate the “Unique Particle Attribution” and I want this to be fixed.
I can edit both XSD, but I want to be able to distribute the first one before finishing the second one.

How can I make this possible (both schemas must be valid when checked by JAXB) ?

Thanks

Answer 1

Some people may say: if you can edit both XSDs, why bother with redefine?

I’ll show you how you can make it work with XSD redefine, at least from an XSD perspective. However, given limitations with JAXB, it’ll not work with it out of the box. If you also use automatic XSD refactoring, as an extra step, then you can make it work and, in the process, you’ll be preserving the value proposition that you see when using xsd:redefine.

So, before that, here is another way which also uses composition, but without xsd:redefine; from a maintenance and validation perspective, you’re getting about the same value and usage.

I’ll refer to your first XSD as Model1 and your second XSD as Model2. I’ll start with one XSD that will give you the “reuse-through-composition” aspect you have with xs:redefine.

Common items, xsd-allow-extension-compatibility-and-validation-common-items.xsd:

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com)-->
<xs:schema xmlns="example" 
       xmlns:xs="http://www.w3.org/2001/XMLSchema" 
       targetNamespace="example" 
       elementFormDefault="qualified" attributeFormDefault="qualified"> 

  <xs:group name="typeA"> 
    <xs:sequence> 
      <xs:element name="elA" type="xs:string" /> 
    </xs:sequence> 
  </xs:group> 

  <xs:element name="root" type="typeA" /> 
</xs:schema> 

Model1 “items”, xsd-allow-extension-compatibility-and-validation-model1-items.xsd:

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com)-->
<xs:schema xmlns="example" 
       xmlns:xs="http://www.w3.org/2001/XMLSchema" 
       targetNamespace="example" 
       elementFormDefault="qualified" attributeFormDefault="qualified"> 

  <xs:complexType name="typeA"> 
    <xs:sequence> 
      <xs:group ref="typeA" /> 
      <xs:any namespace="##any" minOccurs="0" processContents="lax" /> 
    </xs:sequence> 
  </xs:complexType>  
</xs:schema> 

Model2 “items”, xsd-allow-extension-compatibility-and-validation-model2-items.xsd:

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com)-->
<xs:schema xmlns="example" 
       xmlns:xs="http://www.w3.org/2001/XMLSchema" 
       targetNamespace="example" 
       elementFormDefault="qualified" attributeFormDefault="qualified"> 

  <xs:complexType name="typeA"> 
    <xs:sequence> 
      <xs:group ref="typeA" /> 
        <xs:element name="newElement" type="xs:string" />
    </xs:sequence> 
  </xs:complexType>  
</xs:schema> 

If you pass Common Items and Model1, or Common Items and Model2 to JAXB compiler, it’ll create the classes exactly the way you want. For easy of use (testing) and illustration, I’ve created two more XSDs:

Model1:

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com)-->
<xs:schema xmlns="example" 
       xmlns:xs="http://www.w3.org/2001/XMLSchema" 
       targetNamespace="example" 
       elementFormDefault="qualified" attributeFormDefault="qualified"> 
    <xs:include schemaLocation="xsd-allow-extension-compatibility-and-validation-common-items.xsd"/>
    <xs:include schemaLocation="xsd-allow-extension-compatibility-and-validation-model1-items.xsd"/>
</xs:schema> 

Model2:

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com)-->
<xs:schema xmlns="example" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="example" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:include schemaLocation="xsd-allow-extension-compatibility-and-validation-common-items.xsd"/>
    <xs:include schemaLocation="xsd-allow-extension-compatibility-and-validation-model2-items.xsd"/>
</xs:schema>

This is what you get when you run xjc agains Model1:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "typeA", propOrder = {
    "elA",
    "any"
})
public class TypeA {

    @XmlElement(required = true)
    protected String elA;
    @XmlAnyElement(lax = true)
    protected Object any;

    /**
     * Gets the value of the elA property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getElA() {
        return elA;
    }

    /**
     * Sets the value of the elA property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setElA(String value) {
        this.elA = value;
    }

    /**
     * Gets the value of the any property.
     * 
     * @return
     *     possible object is
     *     {@link Element }
     *     {@link Object }
     *     
     */
    public Object getAny() {
        return any;
    }

    /**
     * Sets the value of the any property.
     * 
     * @param value
     *     allowed object is
     *     {@link Element }
     *     {@link Object }
     *     
     */
    public void setAny(Object value) {
        this.any = value;
    }

}

… and when you run xjc agains Model2:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "typeA", propOrder = {
    "elA",
    "newElement"
})
public class TypeA {

    @XmlElement(required = true)
    protected String elA;
    @XmlElement(required = true)
    protected String newElement;

    /**
    * Gets the value of the elA property.
    * 
    * @return
    *     possible object is
    *     {@link String }
    *     
    */
    public String getElA() {
        return elA;
    }

    /**
    * Sets the value of the elA property.
    * 
    * @param value
    *     allowed object is
    *     {@link String }
    *     
    */
    public void setElA(String value) {
        this.elA = value;
    }

    /**
    * Gets the value of the newElement property.
    * 
    * @return
    *     possible object is
    *     {@link String }
    *     
    */
    public String getNewElement() {
        return newElement;
    }

    /**
    * Sets the value of the newElement property.
    * 
    * @param value
    *     allowed object is
    *     {@link String }
    *     
    */
    public void setNewElement(String value) {
        this.newElement = value;
    }

}

Model1 and Model2 XSDs will validate your XMLs exactly the way you’ve intended.

Below if a diagram showing the relationship between the XSD files. Green means “xsd:include”, and the arrow points to the “included”.

UPDATE: I just noticed, based on @Kevin ‘s comment, that you don’t have a maxOccurs on your new element in the redefine. In this case, you could use one single redefine, like so:

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSR Module (http://www.paschidev.com)-->
<xsd:schema xmlns="example" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="example" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:redefine schemaLocation="xsd-allow-extension-compatibility-and-validation.xsd">
    <xsd:complexType name="typeA">
      <xsd:complexContent>
        <xsd:restriction base="typeA">
          <xsd:sequence>
            <xsd:element name="elA" type="xsd:string" /> 
            <xsd:element name="newElement" type="xsd:string" />
        </xsd:sequence>
        </xsd:restriction>
      </xsd:complexContent>
    </xsd:complexType>
  </xsd:redefine>
</xsd:schema>

The only problem seems to be that JAXB (latest) still generates a class using the wildcard.

Update 2: Based on Kevin’s comment, two avoid two redefines, a group should be used instead of xsd:any.

If you in fact plan to use more than one element to extend the new model, then read on. Below is the only way to do that, which requires the use of a group to further refine the any particles.

<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XSR Module (http://www.paschidev.com)-->
<xsd:schema xmlns="example" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="example" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:redefine schemaLocation="xsd-allow-extension-compatibility-and-validation.xsd">
    <xsd:complexType name="typeA">
      <xsd:complexContent>
        <xsd:restriction base="typeA">
          <xsd:sequence>
                  <xsd:element name="elA" type="xsd:string" /> 
                  <xsd:group ref="group1" minOccurs="0">
        </xsd:sequence>
        </xsd:restriction>
      </xsd:complexContent>
    </xsd:complexType>
  </xsd:redefine>
        <xsd:group name="group1">
          <xsd:sequence>
            <xsd:element name="newElement" type="xsd:string" />
        </xsd:sequence>

        </xsd:group>
</xsd:schema>

The net result is that the new XSD can be used to validate Model1, while the original file remains Model1.