Schema Design Patterns: Salami Slice

This is the second of five entries talking about schema design patters.  The previous entry discussed the Russian Doll approach.

In the Salami Slice approach all elements are defined globally but the type definitions are defined locally.  This way other schemas may reuse the elements.  With this approach, a global element with its locally defined type provide a complete description of the elements content.  This information 'slice' is declared individually and then aggregated back together and may also be pieced together to construct other schemas.


<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="" elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="BookInformation">
                <xs:element ref="Title"/>
                <xs:element ref="ISBN"/>
                <xs:element ref="PeopleInvolved">
    <xs:element name="Title"/>
    <xs:element name="ISBN"/>
    <xs:element name="PeopleInvolved">
                <xs:element ref="Author"/>
                <xs:element ref="Publisher"/>
    <xs:element name="Author"/>
    <xs:element name="Publisher">


The advantage is that the schema is reusable since the elements are declared globally.

The disadvantages are: the schema is verbose since each element is declared globally and then referenced to describe the data which leads to larger schema size.  This approach also is not self contained and is coupled.  The elements defined may be contained in other schemas and because of this the schema is coupled to other schema and thus changes to one schema will impact other schemas.

This type of approach is commonly used since it is easy to understand and create reusable components.  It would be an appropriate design to promote reusability and data standardization across differing applications.  This approach is not, however, recommended when modifications to the standard elements will be necessary.  If the length, data types, restrictions or other modifications of the elements need to be changed then this will cause added work as well as a larger impact to other systems.

Comments (11)

  1. This is the third of five entries talking about schema design patterns.&amp;nbsp; In previous entries the…

  2. This is the fourth of five entries talking about schema design patterns.&amp;nbsp; In previous entries the…

Skip to main content