Java Reference
In-Depth Information
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="price" type="xsd:decimal"/>
<xsd:element name="category" type="xsd:NCName"/>
<xsd:choice>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="authors">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="author"
type="xsd:string"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
As you can see, this schema defines a single global element, “book”. The types required
to create a book element are all nested within it. Elements and types cannot be referenced.
Namespaces are localized. The “authors” element redefines its child “author” elements. This
is potentially a maintenance issue.
Russian Doll has certain advantages. For simple schemas, it is easy to read and write because
there is no mixing, no references, no hunting for type definitions. There is no flexibility built
into this design, which makes it predictable. It is easy to understand the intentions of the au-
thor, and you know exactly what the resulting document instance will look like.
Because it is entirely self-contained, schemas that follow this pattern are decoupled from other
schemas. Changing types will not affect other schemas.
The clear disadvantage to Russian Doll with respect to straight XML work is that the types
you carefully define cannot be reused elsewhere. And it can become unwieldy for very large
schemas.
Russian Doll is perhaps an appropriate design to use when wrapping legacy data from a source
that is fairly static, say, a modified DB2 filesystem table on a midrange that holds isolated re-
cords. Within a master data management effort, this sort of definition can be reflected quickly
by generative tools.
Salami Slice
Salami Slice represents the opposite end of the design spectrum from Russian Doll.
