Validation by Projection
How can one validate various document versions?
Multiple document versions that employ extensions require creative approaches in expressing variance in documents, which may result in validation failure.
Documents may employ either wildcards, elements in multiple namespaces or utilize an alternative validation approach: Validation by Projection.
Validation by Projection removes unknown content prior to validation by creating a subset of the original document that is then validated.
Validation by Projection adds transformation requirements to service providers thus increasing the complexity and degrading performance.
PrinciplesStandardized Service Contract
Many of the architectures and strategies for validation apply validity checking to a particular document with a pass or fail result on the document. This assumes that the schemas used in validation are expressive enough for all the potential versions of documents including any extensions. XML Schema 1.0 provides support for wildcard and optional elements in multiple namespaces. Use of wildcard limits the ability for fully describing document, for example it is impossible to have a content model that has optional elements in multiple namespaces with a wildcard at the end.
Figure 1 - Failed Validation
Validation by Projection resolves the stated problem by effectively removing any unknown content prior to validation. Validation by projection is validation performed on the projection of the XML document, where the projection is a subset of the XML document with no other modifications to the contents including order.
An example is the Payment example that defines an InvoiceNumber, Amount and Date as children of PaymentType with no wildcards, ie:
<xsd:element name="Payment" type="tns:PaymentType"/> <xsd:complexType name="PaymentType"> <xsd:sequence> <xsd:element name="InvoiceNumber" type="xsd:string"/> <xsd:element name="Amount" type="xsd:string"/> <xsd:element name="Date" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element>
Payment without wildcards
An example document with an illegal game:consoleVersion element is:
<tns:Payment xmlns:tns="http://www.cutitsaws.com/Payment"> <tns:InvoiceNumber>738345</tns:InvoiceNumber> <tns:Amount>$137.14</tns:Amount> <tns:Date>02.06.08</tns:Date> <product:Description>Ripper2000</product:Description> </tns:Payment>
Payment with illegal product:Description
The above examples show that product:Description is not known. As the Payment Schema does not allow the product:Description, validation of the document would fail. A projection of the document is the document with all unknown elements, in this case the product:Description, removed.
<tns:Payment xmlns:tns="http://www.cutitsaws.com/Payment"> <tns:InvoiceNumber>738345</tns:InvoiceNumber> <tns:Amount>$137.14</tns:Amount> <tns:Date>02.06.08</tns:Date> </tns:Payment>
Example Payment after Projection
Validation by Projection¡¦s benefit is providing a mechanism to handle extra content, which needs to be ignored for validation. More documents that are intended to be valid will be valid under projection by validation. Validation by Projection is an implementation of the Must Ignore Unknown or Must Accept Unknown rules.
Figure 2 - Validation by Projection
Part of validation by projection is determining what to project. The simplest rule for determining what to project is:
Starting at the root element, project any attributes and any elements that match elements in the content model of the current complexType and recurse into each element.
This very simple rule ignores complexities, such as excluding attributes, elements that match wildcards, and global element definitions.
The crucial aspect of validation by projection is that the Accept Set under validation by projection is a superset of the Accept Set without validation by projection. In general, the larger we can make the Accept Set, the greater the chance for versioning. Because the validation by projection Accept Set is potentially a superset of the Accept Set that can be specified by XML Schema, validation by projection will generally allow more languages changes to be compatible changes compared to XML Schema.
Validation by Projection adds message processing logic to a service and inherently requires extra maintenance of transformation of requests to support the projection of messages into the service. Transformation Avoidance is a best practice which improves a service's reusability and composability and would be inherent within this pattern. Transformation in this case is in the removal or simplification of requests versus the traditional element to element mapping. Validation by Projection will also decrease performance because of the extra steps involved.