I am working on a BizTalk solution which uses a schema that was hand created using XML Spy. The schema was created in such a way in which everything was globally available and when I brought it into the BizTalk editor the schema looked to have 266 root nodes. Needless to say this spurred many conversations about schema design and the art of creating reusable types.
So this is the first of 5 blog entries talking about schema design patterns. The last one in the series will be about creating schemas based on the patterns with the BizTalk Editor.
What I have found is that there are four schools of thought on this subject. These are the Russian Doll, the Salami Slice, the Venetian Blind and the Garden of Eden approach.
The main characteristic that differentiates these approaches are whether the elements and types are globally defined. Elements and types that are global are direct children of the <schema> node. Elements and types are considered local when they are nested within other elements and types. If elements or types are global then they are available for reuse by other schemas using either import or include statements. Locally defined elements and types are not available for reuse.
In the Russian Doll approach, the schema has one single global element – the root element. All other elements and types are nested progressively deeper giving it the name due to each type fitting into the one above it. Since the elements in this design are declared locally they will not be reusable through the import or include statements. This will not change if the elements are namespace qualified or namespace unqualified.
<?xml version=”1.0″ encoding=”UTF-8″?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” elementFormDefault=”qualified” attributeFormDefault=”unqualified”>
The advantages of the Russian Doll approach are: The schema is self contained as it has all of its parts in the schema and does not interact with other schemas. In as much as it is self contained it is also decoupled. Since the content of the schema is not visible to other schemas, changes to the schema are decoupled from other schema components.
The disadvantage is that it is not reusable.
This type of approach would be appropriate for use within a single application or for migration of data from legacy systems.