The revised schema looks like this, with additions highlighted in bold:

<?xml version=”1.0” encoding=”utf-8”?>

<xs:schema xmlns=”urn:example.com:productsearch:products”

                xmlns:xs=”http://www.w3.org/2001/XMLSchema”

                elementFormDefault=”qualified”

                targetNamespace=”urn:example.com:productsearch:products”

                id=”Products”>

  <xs:element name=”Products” type=”Products” />

  <xs:complexType name=”Products”>

    <xs:sequence>

      <xs:element minOccurs=”0” maxOccurs=”unbounded” name=”Product” type=”Product” />

    </xs:sequence>

  </xs:complexType>

  <xs:complexType name=”Product”>

    <xs:sequence>

      <xs:element name=”CatalogueID” type=”xs:int” />

      <xs:element name=”Name” type=”xs:string” />

      <xs:element name=”Price” type=”xs:double” />

      <xs:element name=”Manufacturer” type=”xs:string” />

      <xs:element name=”InStock” type=”xs:string” />

      <xs:element minOccurs=”0” maxOccurs=”1” name=”Extension” type=”Extension” />

    </xs:sequence>

  </xs:complexType>

  <xs:complexType name=”Extension”>

    <xs:sequence>

      <xs:any minOccurs=”1” maxOccurs=”unbounded” namespace=”##targetNamespace” processContents=”lax” />

    </xs:sequence>

  </xs:complexType>

  <xs:element name=”Description” type=”xs:string” />

</xs:schema>

Note that the first version of the extensible schema is forwards-compatible with the second and that the second is backwards-compatible with the first. This flexibility, however, comes at the expense of increased complexity. Extensible schemas allow us to make unforeseen changes to an XML language, but by the same token, they provide for requirements that may very well never arise; in so doing, they obscure the expressive power that comes from a simple design and frustrate the meaningful representation of business information by introducing meta-informational container elements into the domain language.

We’ll not discuss schema extensibility further here. Suffice to say, extension points allow us to make backwards- and forwards-compatible changes to schemas and documents without breaking service providers and consumers. Schema extensions do not, however, help us manage the evolution of a system when we need to make what is ostensibly a breaking change to a contract.