Schema Design Patterns: Garden of Eden
The Garden of Eden approach implements characteristics of the Venetian Blind and Salami Slice approach. Like the Salami Slice the Garden of Eden uses a modular approach by defining all elements globally and like the Venetian Blind approach all type definitions are declared globally. Each element is globally defined as an immediate child of the <schema> node and its type attribute can be set to one of the named complex types. Since the elements are globally declared, the namespace must be exposed no matter what the settings of the elementFormDefault attribute is. Therefore, if the elementFormDefault attribute is set to qualified, this does not change the content and structure of the instance document but if the attribute is set to unqualified then the local elements in the instance document must not be qualified with the prefix of the namespace prefix.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"
<xs:element name="BookInformation" type="BookInformationType"/>
<xs:element ref="PeopleInvolved" maxOccurs="unbounded"/>
<xs:element name="PeopleInvolved" type="PeopleInvolvedType"/>
The advantage of this approach is that the schemas are reusable. Since both the elements and types are defined globally both are available for reuse. This approach offers the maximum amount of reusable content.
The disadvantages are the that the schema is verbose. Since everything is globally declared and then referenced the size of the schema is increased. Also, the schema is not self contained and can be coupled with other schemas thus possibly affecting other schemas with any changes made. Lastly, there is no option to hide the namespace since they are always exposed on globally defined items.
This type of approach is good when need the flexibility of both global elements and global types. This is also a good approach when you need to allow other schema authors to extend or restrict your types or you want to allow them to compose custom types by picking constituent types from your schema. This would be an appropriate design when you are creating general libraries in which you can afford to make no assumptions about the scope of the schema elements and types and their use in other schemas particularly in reference to extensibility and modularity.