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 which imports a stylesheet module called param.xsl
which only defines XSLT parameters and other modules called chunk-common.xsl
and chunk-code.xsl
. The module chunk-common.xsl
defines a named 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 validate such a module properly a validation scenario must be defined which sets 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 by validation the same errors that would be issued by transformation.
To define a validation scenario first open the Configure Validation Scenario dialog which displays a list of reusable scenarios for documents of the same type as the current document. You do this with the Configure Validation Scenario action available on the menu and on the toolbar of the <oXygen/> plugin
A validation scenario is created or edited in a special dialog opened with the New button or with the Edit one.
The table columns are:
The URL of the main module which includes the current module and which is the entry module of the validation process when the current module is validated.
One of the engines available in <oXygen/> for validation of the type of document to which the current module belongs.
If this option is checked then the validation operation defined by this row of the table is applied also by the Validate as you type feature. If the Validate as you type feature is disabled in Preferences then this option does not take effect as the Preference setting has higher priority.
A list of Java jar files or classes which implement extensions of the language of the current module. For example when the current module is an XSLT stylesheet an extension jar contains the implementation of the XSLT extension functions or the XSLT extension elements used in the stylesheet which includes the current module.
A row of the table is created or edited in the following dialog:
The components of the dialog are the same as the columns of the table displayed in the scenario edit dialog. The URL of the main module can be specified with the help of a file browser for the local file system (the Open FTP / SFTP / WebDAV dialog opened by the button or by inserting an editor variable from the following pop-up menu:
button), with the help of theA 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 a complex XQuery with a main module which imports modules developed independently but validated in the context of the main module of the query and an XML document in which the master file includes smaller fragment files using XML entity references.