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. You do this with the Configure Validation Scenario action available on the menu . You can use the default engine set in and on the toolbar of the <oXygen/> pluginPreferences, or use a custom validation scenario. The list of reusable scenarios for documents of the same type as the current document is displayed.
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. In an XQuery validation scenario the default validator of <oXygen/> (Saxon 9) or any connection to a database that supports validation (Oracle 11g, Berkeley DB XML Database, IBM DB2, eXist XML Database, MarkLogic, Microsoft SQL Server, Software AG Tamino, Documentum xDb (X-Hive/DB) XML Database, TigerLogic, MySQL) can be set as validation engine.