Java Reference
In-Depth Information
<xsd:element name= "InventoryList">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded" >
<xsd:element name= "Desk"
type="DeskType" />
<xsd:element name= "Chair"
type="ChairType" />
</xsd:choice>
</xsd:complexType>
</xsd:element>
We don't limit the structure of the choice types because the types are no
longer derived from a common type. Unfortunately, we can no longer extend
our list by adding new elements to our substitution group. With this
approach, we have taken one step forward and one step back.
Use an abstract type and type substitution
A third approach is to define an abstract type within our schema, and then
substitute a type in our instance document. Here is our schema:
<xsd:element name= "InventoryList">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="FurnitureItem"
type="FurnitureItemType"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
FurnitureItemType is our abstract type. We can substitute a compatible type—
meaning any type derived from the abstract type—in the instance document.
We have the same extensibility advantages as with the first example, and less
coupling. We can also process the list items over a common interface. How-
ever, we're still limited to elements that are derived from the same type.
Use a dangling type (not supported yet) or the any construct
With this approach, we're going to define a type that's defined in another
namespace. We'll then import the type, but in the schema, we won't specify
the schema location. This will allow us to delay the binding of our type until
runtime, since the schema location can be provided in our runtime document.
Search WWH ::




Custom Search