A complex XML document is usually split in smaller interrelated modules which do not make much sense individually and which cannot be validated in isolation due to interdependencies with the other modules. A mechanism is needed to set the main module of the document which in fact must be validated when an imported module needs to be checked for errors.
A typical example is the chunking DocBook XSL stylesheet which has chunk.xsl as the main module and param.xsl, chunk-common.xsl and chunk-code.xsl as imported modules. param.xsl only defines XSLT parameters. The module chunk-common.xsl defines a XSLT template with the name chunk which is called by chunk-code.xsl. The parameters defined in param.xsl are used in the other modules without being redefined.
Validation of chunk-code.xsl as an individual XSLT stylesheet issues a lot of misleading errors referring to parameters and templates used but undefined which are only caused by ignoring the context in which this module is used in real XSLT transformations and in which it should be validated. To properly validate such a module, a validation scenario must be defined to set the main module of the stylesheet and also the validation engine used to find the errors. Usually this is the engine which applies the transformation in order to detect in validation the same errors that would be issued by transformation.
A second benefit of a validation scenario is that the stylesheet can be validated with several engines to make sure that it can be used in different environments with the same results. For example an XSLT stylesheet needs to be applied with Saxon 6.5, Xalan and MSXML 4.0 in different production systems.
Other examples of documents which can benefit of a validation scenario are: