⬆️ ⬇️

XSD Design Patterns





In the life of every analyst and programmer, a day comes when he learns about the existence of patterns (patterns) for designing XML schemas and his life is changing. For me, for example, this knowledge began to comprehend the beauty of design.



Today I want to talk about what XSD design patterns are, about the advantages and disadvantages of each, and why we chose the Garden of Eden for our tasks.



For example, take the following XML document as a data source.

')

<?xml version="1.0" encoding="UTF-8"?> <Customer> <CustomerId>100</CustomerId> <FirstName></FirstName> <LastName></LastName> <Address> <StreetAddress> 2</StreetAddress> <City></City> <Zip>115088</Zip> </Address> </Customer> 


And let's see how you can describe the same structure of an XML document in different ways.

The basis of the patterning is the definition of global elements and / or data types within XSD.



Matryoshka (Russian Doll)







The essence of the template is that the schema is a mirror of the XML document that it describes: if complex elements contain other complex elements within themselves, and those in turn contain simple ones, then in XSD descriptions of such elements will be nested into each other. The name of the pattern was in honor of the world-famous dolls of our dolls, in the same way as the child elements in the pattern are encapsulated into the parent ones.



The scheme describing the structure of our source file using the “Matryoshka” pattern looks like this:



 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:element name="Customer"> <xsd:complexType> <xsd:sequence> <xsd:element name="CustomerId" type="xsd:int" /> <xsd:element name="FirstName" type="xsd:string" /> <xsd:element name="LastName" type="xsd:string" /> <xsd:element name="Address"> <xsd:complexType> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 


Characteristics of the template:





Salami (Salami Slice)







The essence of the template is that the described XML document is divided into constituent elements, each of which is described as global in XSD. Then the described elements are connected together.



The diagram describing the structure of the source file using the “Salami” template looks like this:



 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:element name="CustomerId" type="xsd:int" /> <xsd:element name="FirstName" type="xsd:string" /> <xsd:element name="LastName" type="xsd:string" /> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> <xsd:element name="Customer"> <xsd:complexType> <xsd:sequence> <xsd:element ref="tns:CustomerId" /> <xsd:element ref="tns:FirstName" /> <xsd:element ref="tns:LastName" /> <xsd:element name="Address"> <xsd:complexType> <xsd:sequence> <xsd:element ref="tns:StreetAddress" /> <xsd:element ref="tns:City" /> <xsd:element ref="tns:Zip" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 


Characteristics of the template:





Venetian blinds (Venetian Blind)







The essence of the template is that the described XML document is divided into complex types, each of which is described in the XSD as global. Then the root element is declared, corresponding to a global type that connects the schema together.



The scheme describing the structure of the source file using the Venetian Blinds template looks like this:



 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:complexType name="AddressType"> <xsd:sequence> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="CustomerType"> <xsd:sequence> <xsd:element name="CustomerId" type="xsd:int" /> <xsd:element name="FirstName" type="xsd:string" /> <xsd:element name="LastName" type="xsd:string" /> <xsd:element name="Address" type="tns:AddressType" /> </xsd:sequence> </xsd:complexType> <xsd:element name="Customer" type="tns:CustomerType" /> </xsd:schema> 


Characteristics of the template:





Garden of Eden







The Garden of Eden is good because it defines each element and composite data type as global. This allows you to refer to any type or element within one XSD or from any other XSD and even from WSDL. This is the only way to fully control the semantics and types and elements.



The scheme describing the structure of the source file using the template "Garden of Eden" looks like this:



 <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Customer" xmlns:tns="http://www.example.org/Customer" elementFormDefault="qualified"> <xsd:element name="CustomerId" type="xsd:int"/> <xsd:element name="FirstName" type="xsd:string"/> <xsd:element name="LastName" type="xsd:string"/> <xsd:element name="StreetAddress" type="xsd:string"/> <xsd:element name="City" type="xsd:string"/> <xsd:element name="Zip" type="xsd:string"/> <xsd:element name="Address" type="tns:AddressType"/> <xsd:element name="Customer" type="tns:CustomerType"/> <xsd:complexType name="AddressType"> <xsd:sequence> <xsd:element ref="tns:StreetAddress"/> <xsd:element ref="tns:City"/> <xsd:element ref="tns:Zip"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="CustomerType"> <xsd:sequence> <xsd:element ref="tns:CustomerId"/> <xsd:element ref="tns:FirstName"/> <xsd:element ref="tns:LastName"/> <xsd:element ref="tns:Address"/> </xsd:sequence> </xsd:complexType> </xsd:schema> 


Characteristics of the template:





Template selection



When choosing a template, it is important to consider several criteria:

  1. As far as possible to reuse schema components;
  2. How easy it is to work with the scheme;
  3. How much the components of the schema should be interdependent or independent.




Often when choosing a design pattern, you have to find a balance between the ability to reuse the components of the circuit and the depth of the relationship between the components. The figure shows the potential of each of the patterns in terms of these two aspects.







Those schemes in which component reuse is well supported, on the other hand, have strong interconnections between components. If necessary, something to change in such a scheme, the developer of the scheme may be faced with the fact that you will have to change a lot of related elements and / or types. Such schemes are subsequently difficult to manage.



In general, the following template selection rules can be displayed:





The most important thing for us in the project was the reuse of types and elements of the scheme, and secondly the total semantic control of names. The choice of pattern was obvious - the Garden of Eden.



A small lyrical digression. The most interesting use of XML design patterns in my memory has been and remains the hypnosis of the audience. One of our titled analyst likes to take the initiative through a story on this topic. I noticed time, after 5 minutes the listeners look dim, and they go somewhere far in themselves. On the "Garden of Eden" most consciousness is turned off.



And in conclusion I want to add that template mixes are also possible, we met with them.



Sources and Resources:

XML Schema specification

Schema scope: Primer and best practices

Introducing Design Patterns in XML Schemas

Source: https://habr.com/ru/post/259167/



All Articles