Java Reference
In-Depth Information
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.
7.6.3
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:complexType>
<xsd:sequence>
<xsd:element ref="FurnitureItem"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name= "Desk"
substitutionGroup="FurnitureItem"
type="DeskType" />
<xsd:element name= "Chair"
substitutionGroup="FurnitureItem"
type="ChairType" />
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
base types.
Use choice elements
We can instead implement our schema with an unbounded list of choices. This
is the code for the
<choice>
approach:
