Instead, we should prefer type definitions to elements. If necessary, we can
always replace the type with an element in another schema document. This
way, we have the ability to choose compatible subtypes or different elements at
a later time. In essence, we're delaying the binding of a specific element to a
schema. As with Java interfaces, minor exceptions exist, but the general rule is
that in schemas, we should use XML types rather than elements.
Restrictive variable-content containers
Many XML designs call for containers of variable content. A variable-content
container is a collection of components; these components may be of similar
or unrelated types, either simple or complex. Examples include inventory lists,
sales catalogs, and recipes. The XML Schema: Best Practices website describes
four approaches , with varying flexibility
Use an abstract element and substitute an element
With this approach, we declare an abstract element and a substitution group.
In this example, we're inventorying office furniture, and our inventory list
contains desks and chairs. This is the code:
<xsd:element name= "InventoryList">
<xsd:element name= "Desk"
<xsd:element name= "Chair"
This approach is fairly flexible, but it does force us to derive elements of the
inventory from the FurnitureItem 's type. In essence, we're limiting ourselves
to custom types. We're also limiting the structure of the derived types to the
Use choice elements
We can instead implement our schema with an unbounded list of choices. This
is the code for the <choice> approach: