Re: [xml-dev] reasons why an XML instance must be validated witha XML sc

[Rick Jelliffe <rjelliffe@allette.com.au>]

It depends on how much the senders and receivers know and trust each 
other, how they are organized, and how they have used XSD.

At one extreme, you have multiple parties of different levels of 
technical ability generating data:  the less trust there is, the more 
that constant validation is useful.

At another extreme, a receiver might implement their system robustly, to 
allow for schema upgrades and different providers, so that only 
documents with missing essential items are rejected, and they might 
trust their senders. These don't really need to do any validation, 
except for initial debugging as a kind of unit testing. Indeed, they 
might have a positive requirement to accept documents that are not valid 
in areas that are irrelevant to them.

The big problem with schemas in general is that they fall down whenever 
you get the situation where the receiver has a pipeline or star of 
multiple internal recipients of that data: each may require elements 
that the general schema does not require. Many times the cardinality of 
an element comes from business rules, and where you have different 
conflicting business rules, the scheme ends up heading towards either 
value-debilitating openness or towards adding extraneous contstraints.

So you need to decide what the function of the gateway is: is it just to 
weed out utterly impossible documents and then pass them through to 
individual systems, which each will have their own checking?  Or is it a 
guardian that insures that all documents that pass through can be used 
by any of the processes behind it?  In both cases, I suggest it is 
better to have more open schemas, and separate the constraints (on 
cardinality, value-spaces, etc) to other schemas, even using another 
language better suited to this like Schematron.

Another way to look at validation is to use Quality Assurance/Quality 
Control approaches. Will validation give you useful QA or QC 
information? Is the value of that QA or QC information worth the cost of 
validation? Does the sample point match a feedback point, so that the 
information can be effectively utilized?  Should sampling techniques be 
used? Should initial-source acceptance test techniques be used?  Does 
the schema actually test things that are weak spots in your system, or 
does will it remove effort and focus from actually reported issues? Is 
there a process to allow actual problems to be rapidly fed back so that 
the schema can be enhanced to meet real emerging requirements?

Cheers
Rick Jelliffe