Java Reference
In-Depth Information
can specify a type specification for
frame_type
. We'll then have a flexible and
powerful schema.
Using static content models
A limited-content model will not allow instance models to extend the types
beyond what is in the schema definition. Consider the definition of a
photograph:
<xsd:element name= "Photograph">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="photographer" type="string" />
<xsd:element name="subject" type="string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
In this example, we'll always be limited to a sequence containing the photog-
rapher and the photograph subject. If we stay with the same schema, we'll
never be able to extend the photograph element by adding, say, a color or
black-and-white field, a resolution field, or a size field.
Instead, we can add placeholders to the schema in spots that we are likely
to extend:
<xsd:element name= "Photograph">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="photographer" type="string" />
<xsd:element name="subject" type="string" />
<xsd:any namespace="##any" minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
With the revised schema, we can add any number of new elements or types to
our photograph schema, and the added components can be contained in their
own namespace to avoid collisions.
Element over type
Preferring interfaces over abstract classes is one of the Java programming
hygiene rules we'll introduce in chapter 9. Abstract classes limit us to a single
inheritance chain and restrict how our code can be extended, while an inter-
face gives us much more flexibility. In
XML
, we're often faced with making a
similar decision between types and elements. In a schema, many times ele-
ments are specified, which of course limits flexibility.
