WCF is mostly used within a code first implementation. The data contract and service operations are implemented as methods within a class which are decorated with attributes (like [DataContract] and [DataMember]). With these attribute the types define that they are serializable with a serializer such as the DataContractSerializer. The DataContractSerializer is an optimized serializer which is faster than the XmlSerializer (http://www.danrigsby.com/blog/index.php/2008/03/07/xmlserializer-vs-datacontractserializer-serialization-in-wcf/). A consequent of this optimalization is that only a subset of the XML Schema (XSD) is supported: http://msdn.microsoft.com/en-us/library/ms733112.aspx
When working with existing systems, it is most times not possible to use the code first approach for the definition of the data contract. XSD and WSDL are exposed by existing services which makes client proxy and data contract code generation possible with the use of svcutil. By default svcutil tries to use to DataContractSerializer and falls back to the XmlSerializer when usage of the DataContractSerializer is not possible (it is possible to force the use of the data contract serializer by supplying the /serializer:datacontractserializer argument, which not falls back to the XmlSerializer but returns an error when it is not able to generate the code).
Within a situation that WSDL and XSD are leading but changes can be made to support the DataContractSerializer, it can be time consuming to update those service definitions files. The svcutil tool gives limited feedback when it fails to use the DataContractSerializer and it does not give you a clear overview of the issues that should be solved to make it compliant to this serializer.
Schematron
Schematron is a rule-based validation language for making assertions about the presence or absence of patterns in XML trees. It is a structural schema language expressed in XML using a small number of elements and XPath. (http://en.wikipedia.org/wiki/Schematron). With the use of a Schematron rule set file, additional conditions can be defined for the data contract schema definition.
Schematron (http://www.schematron.com/) is an ISO standard (http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip) and makes it possible to define constraints which cannot be expressed/defined within a XML Schema (XSD). It is possible to define rules which take related elements into account. Within a Schematron rule set file, rules are made by specifying assertions. An example of a rule
<sch:pattern id="schema-element-attribute-error"> <sch:rule context="xsd:schema/xsd:element"> <sch:assert test="@nillable = 'true'">Must be true for associated GEDs.</sch:assert> </sch:rule> </sch:pattern>
Above rules makes sure that global element declarations (xsd:element directly defined within xsd:schema) should have the nillable=”true” attribute.
Besides <assert> there is also a <report> assertion. When the Schematron rule set is applied on an XML file, <assert> is logged when the condition fails (positive assertions). On the other side <report> is logged (within the output file) when the condition is met (negative assertions). For example when above rule fails on the supplied data contract schema definition, the output file (SVRL, Schematron Validator Report Language) will contain:
<svrl:active-pattern id="schema-element-attribute-error" name="schema-element-attribute-error"/> <svrl:fired-rule context="xsd:schema/xsd:element"/> <svrl:failed-assert test="@nillable = 'true'" location="/*[local-name()='schema' and namespace-uri()='http://www.w3.org/2001/XMLSchema']/*[local-name()='element' and namespace-uri()='http://www.w3.org/2001/XMLSchema'][1]"> <svrl:text>Must be true for associated GEDs.</svrl:text> </svrl:failed-assert> <svrl:fired-rule context="xsd:schema/xsd:element"/>
whereby the location of the element causing this failure is part of the result message (location attribute).
Applying an schematron ruleset
A Schematron rule set file is converted to an XSLT file which will be applied on the XML file on which the assertions should be executed. This is a pipelined process whereby the Schematron file is tranformed by different XSL files (and an XSLT engine) as shown in the diagram below
When using the basic elements of Schematron, only one transformation is needed before it can be applied on a file which should be validated. I used the Schematron XSLT1 implementation (http://www.schematron.com/tmp/iso-schematron-xslt1.zip) together with the free AltovaXML XSLT Engine (http://www.altova.com/altovaxml.html)
AltovaXML /xslt1 iso_svrl_for_xslt1.xsl /in datacontract.sch /out datacontract.xsl AltovaXML /xslt1 datacontract.xsl /in <xsd schema which should be checked> /out result.svrl
Data Contract Validator
With the use of Schematron it is possible to make a data contract serializer validator, which gives you a quick overview of issues to make use of the Data Contract Serializer possible. I developed a first implementation of this rule set based on the Data Contract Schema Reference (http://msdn.microsoft.com/en-us/library/ms733112.aspx). Not all rules are implemented yet.
When validating a data contract XSD there are errors (a Global Element Declarations should have @nillable=’true’) and warnings (attribute @id is ignored). To distinguish between both validation types I used for the errors, and for warnings/verbose information.
You can download the Data Contract Schematron Rule set at http://johandekoning.codeplex.com/SourceControl/changeset/view/48265#831939



