SyntacticValidationHandler : Handling composed schemas while validating the request / response object.

The Quick starts and the Template projects are now using a simple request / response schema at this point. But, if anyone wants to use composed multiple schemas then here is an example:

The composed multiple schemas can be handled / referred in two different ways. This is based on the fact whether the sub-schema belongs to the same name space as that of the main schema or to a different one.

Option-1: If the sub-schema belong to the same name space as that of the main schema then it can be referred in the main schema using the 'include' element.

Schema of the new Request object (referencing the UserInfo schema using 'include' element) - DepositReq.xsd:

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="requestDeposit" targetNamespace="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/requestDeposit.xsd" elementFormDefault="qualified"
xmlns:mstns="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/requestDeposit.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="UserInfo.xsd" />
<xs:element name="DepositReq">
<xs:complexType>
<xs:sequence>
<xs:element name="UserInf" type="mstns:UserInfo" />
<xs:element name="AccountId" type="xs:int" />
<xs:element name="Amount" type="xs:decimal" />
<xs:element name="Date" type="xs:date" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>


Schema of the UserInfo object (having the same name space) - UserInfo.xsd :

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="userInformation" targetNamespace="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/requestDeposit.xsd" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="UserInfo">
<xs:sequence>
<xs:element name="UserId" type="xs:string" />
<xs:element name="UserName" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>

In this example, the DepositReq.xsd & the UserInfo.xsd are having the same 'targetNamespace' here and the DepositReq.xsd is referring to the UserInfo schema through the 'include' element.



Option-2: If the sub-schema belong to a different name space then it can be referred in the main schema using the 'import' element.

Schema of the new Request object (referencing the UserInfo schema using 'import' element) - DepositReq.xsd:

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="requestDeposit" targetNamespace="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/requestDeposit.xsd" elementFormDefault="qualified"

		      xmlns:mstns="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/requestDeposit.xsd"
		      xmlns:uins="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/userInformation.xsd"
		      xmlns:xs="http://www.w3.org/2001/XMLSchema">
		      <xs:import namespace="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/userInformation.xsd" schemaLocation="UserInfo.xsd" />
		      <xs:element name="DepositReq">
		            <xs:complexType>
		                  <xs:sequence>
		                        <xs:element name="UserInf" type="uins:UserInfo" />
		                        <xs:element name="AccountId" type="xs:int" />
		                        <xs:element name="Amount" type="xs:decimal" />
		                        <xs:element name="Date" type="xs:date" />
		                  </xs:sequence>
		            </xs:complexType>
		      </xs:element>
	

</xs:schema>


Schema of the UserInfo object (having a different name space) - UserInfo.xsd :

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="userInformation" targetNamespace="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/userInformation.xsd" elementFormDefault="qualified"

		      xmlns:mstns="http://www.microsoft.com/practices/referencearchitecture/services/03-08-2004/userInformation.xsd"
		      xmlns:xs="http://www.w3.org/2001/XMLSchema">
		            <xs:complexType name="UserInfo">
		                  <xs:sequence>
		                        <xs:element name="UserId" type="xs:string" />
		                        <xs:element name="UserName" type="xs:string" />
		                  </xs:sequence>
		            </xs:complexType>
	

</xs:schema>

In this example, the DepositReq.xsd & the UserInfo.xsd are having a different 'targetNamespace' here and the DepositReq.xsd is referring to the UserInfo schema through the 'import' element.


Once we have these schemas in place then the user has to make the changes on the client application where the request object is getting created or populated. There is no change necessary with in the EDRA framework to support this behavior.