[SOLVED] Is modifying existing XSD type by extending it from exact same type backward compatible?

Is modifying existing XSD type by extending it from exact same type backward compatible?

I made earlier XSD+WSDL for a WS that is implemented by a customer. We implement the client. I have type like this in WS Create-operation:

<xs:complexType name="tWorkCreate">
 <xs:sequence>
  <xs:element ref="plan:workkey"  />
  <xs:element ref="plan:workdata"  />
 </xs:sequence>
</xs:complexType>

Now I would like to use the same type for new Update-operation, but naming is wrong. So I plan to do like this:

<xs:complexType name="tWorkSet">
 <xs:sequence>
  <xs:element ref="plan:workkey"  />
  <xs:element ref="plan:workdata"  />
 </xs:sequence>
</xs:complexType>


<xs:complexType name="tWorkCreate">
 <xs:complexContent>
  <xs:extension base="tWorkSet">
    <xs:sequence>
    </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

and use tWorkSet directly for Update operation (tWorkCreate operation would be the same). The existing customer does not need (and is not implementing) Update. The reason for not duplicating the type is e.g that we could handle both Update and Create similarly in code. So is it better just to duplicate the type or is this extension scenario sensible?

Solution

Yes, refactoring type definitions in this manner is a good idea and is backward compatible¹. All of the same XML documents that were valid before the type refactoring will be valid after the refactoring. In fact, it's better than backward compatible because exactly the same set of XML documents that were valid before the change will be valid after the change.

_{¹Assuming that clients have no direct dependencies against the type names themselves such as via JAXB bindings or xsi:type use in XML doc instances. [Thanks to Petru Gardea.]}