The benefit in your example is rather questionable. However, when you have a number of elements that are in a category of sorts, such as when you buy something at a store, including employee discounts:
Code:
<xs:complexType name="item.type">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="price" type="xs:decimal"/>
<xs:element name="discount" type="xs:decimal" minOccurs="0"
default="0.0"/>
<xs:element name="employee-discount" type="xs:decimal" minOccurs="0"
default="0.0"/>
</xs:sequence>
</xs:complexType>
Code:
<xs:complexType name="employee-item.type">
<xs:complexContent>
<xs:restriction base="item.type">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="price" type="xs:decimal"/>
<xs:element name="discount" type="xs:decimal" minOccurs="0"
default="0.0"/>
<xs:element name="employee-discount" type="xs:decimal"
fixed="0.15"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
Then instead of using the following:
Code:
<item>
<name>Example</name>
<price>9.99</price>
</item>
<item>
<name>Example</name>
<price>9.99</price>
<employee-discount>0.15</employee-discount>
</item>
You could use this instead:
Code:
<item>
<name>Example</name>
<price>9.99</price>
</item>
<employee-item>
<name>Example</name>
<price>9.99</price>
</employee-item>
Again, a dumb example, but when you consider adding more elements (e.g. instead of "price", you have "price" and "profit"), you might find it useful. Honestly, I don't typically see using restrictions in this way beneficial. Extensions are more useful for this sort of thing...adding elements and groups rather than restricting elements. I don't find much use for restrictions in complex content. Enumerations in simple content and simple types are what I use them for most commonly.
Bookmarks