A "Well Formed XML" document means that it has a correct XML syntax. Using the Check XML Form function checks that your document conforms to the XML syntax rules.
A "Valid" XML document is a "Well Formed" XML document, which also conforms to the rules of a Document Type Definition (DTD) , XML Schema or other type of schema, which defines the legal elements of an XML document.
When creating an XML document, errors can be introduced. When working with large projects or many files, the probability that the errors will occur is even greater. Determining that your project is error free can be time consuming and even frustrating. For this reason <oXygen/> provides functions that enable easy error identification and rapid error location.
The XML schemas gain more and more usage over DTDs. <oXygen/> integrates always the latest version of the Xerces-J XML parser to validate documents against XML Schemas. Xerces is the best open source XML parser and is widely used in the enterprise servers.
Most of the XML Schema related errors are reported not only with a descriptive message but also with a pointer (URL) to the exact location in the XML Schema specification that is related with that error, thus if you are interested in more details about that error or if you want to have the normative words of the specification that is just a click away, no need to spend a lot of time to find the relevant place in the schema specification documents.
Validation scenarios are a very powerful feature and they solve a number of important issues when working with XML and XML related technologies. They allow working with modules and performing multiple validations in one action.
By default the validation of a document is done by using a processor (XML parser, XSLT transformer, XQuery engine, etc.) to analyze the current file. The validation scenario allows to specify a set of files to validate and for each file what processor to use and whether or not to perform continuous validation. Thus if you work on a module you can set the validation on the master file, the file that refers that module. Also you can perform multiple validations with different processors or on different files.
Let's imagine you work on a big XML document and at some moment you decide to split that into more files and use external entities to include those files into a master document. When you edit one of those files then what you want to check is that the master document that includes the current file is valid. The <oXygen/> validation scenarios allow you to specify exactly that and validate the master document that includes the current file instead of validating only the current file. Thus the current file gets validated in the context it is used from.
XSLT stylesheets (as in fact many other XML related technologies like XQuery, Relax NG, etc.) can be invalid by themselves but they can be valid in context when imported or included in other files. For instance one can write a module XSLT stylesheet that makes a reference to a named template or variable that is not defined in the current file but it is defined in a master file that includes or imports this XSLT stylesheet. In this case if you check the XSLT module for validity you will get an error that there is no such template or variable with that name. However when you validate the master XSLT stylesheet that imports or includes this module it will be valid. <oXygen/>'s custom validation scenarios allow to specify the master file that refers the module to be validated so that the XSLT module will be validated in context.
Some XML technologies are complicated as it is the case with XML Schema for instance, some processors have their particularities as in the case of different XSLT processors. When you edit documents that are supposed to be public or that are supposed to work no matter what engine they will be used with then it is best to check your file against all the engines your document will be used with. The <oXygen/> validation scenarios allow you to specify multiple validations to be performed and choose the engine for each validation. Thus you can set for instance any of the processors <oXygen/> has support for XML Schema validation (there are 6 XML Schema processors <oXygen/> supports and others can be added as external processors) when you edit a schema, and <oXygen/> will validate your schema against all in one action, thus you can easily check that your schema will work no matter what processor will be used.
Imagine you have a set of instance documents and you want to change their schema while making sure they are still valid. <oXygen/> validation scenarios allow you to configure multiple validations, on each instance document and on the schema file and all will be performed in a single action, thus you are sure that the schema is valid and your instances are still valid against the updated schema.
When you work with modules there is also the use case to reuse them in different contexts. <oXygen/> allows you to validate the module in all the contexts it is used from as the validation scenarios allow setting multiple files for validation. Thus you can add there all the master files that use the module and in a single action you check that the module is valid in all contexts it is used from.
<oXygen/> can be configured to mark validation errors in the edited document as you modify it using the keyboard. If you enable the Validate as you type option after the configured delay from the last key typed the validation errors will be highlighted automatically in the editor panel.
At the bottom of the editing area, there is a reporting label that presents the message of the error that is closest to the caret position.
The errors, including the ones generated by the continuous validation are marked in place by underlining the error location. The locations are also marked in an overview ruler that allows quick navigation between the error markers.
<oXygen/> has built-in support for: Xerces, LIBXML, XSV, Saxon SA, MSXML4.0, MSXML .NET and SQC.
In addition to these ones that are pre-configured, you can add your own validator.
<oXygen/> can validate XML documents using Schematron schemas and XML Schemas or Relax NG Schemas that contain embedded Schematron rules. Also it includes editing and validation support for Schematron schemas.
For validation <oXygen/> uses the Skeleton XSLT processor that is Schematron 1.5 conformant.
For schemas that define different validation phases <oXygen/> shows automatically a dialog where the validation phase can be selected.
Starting with version 8.2 <oXygen/> includes support for ISO Schematron.
<oXygen/> has a Schematron editor that detects automatically from the namespace that the edited Schematron schema is ISO Schematron. It offers content completion with documentation for the ISO Schematron elements, attributes and values and also features continuous validation.
When editing XML Schemas <oXygen/> offers inside xs:annotation/xs:appinfo ISO Schematron proposals through content completion thus allowing easier editing of Schematron embedded rules.
The validation support from <oXygen/> handles validation against ISO Schematron schemas. This includes validation on request, continuous validation and batch validation.
ISO Schematron rules can be embedded in other schemas. <oXygen/> offers validation against ISO Schematron rules embedded in Relax NG schemas or in XML Schemas.
<oXygen/> handles also ISO Schematron schemas that contain abstract patterns or references to other ISO Schematron files through sch:include. There is a limitation on schema validation that checks the document as it is, without expanding the includes.
The diagnostics messages issued by a Schematron schema are displayed together with the other validation errors. Schematron report messages are treated as warnings.
The XPath 2.0 checks used in an ISO Schematron schema or a Schematron 1.5 schema can be executed optionally with Saxon EE instead of Saxon B in order to access the schema aware features of Saxon EE. The Saxon EE processor is an extension of the Saxon B one and is bundled with <oXygen/>.
The allow-foreign parameter set for Schematron processing allows XML elements which are outside the ISO Schematron namespace like xsl:function and xsl:import-schema to be used inside an ISO Schematron schema.
An XML Catalog defines mappings between schema locations. For example if you are using DocBook, the default documents are using the DTDs located on the Oasis web site. This means that for each validation the DTDs are downloaded - operation that takes time. To overcome this problem, the <oXygen/> XML Editor makes use of several catalogs for DocBook, TEI and XHTML frameworks. These are automatically set up at the editor first run.
The catalog list can be managed from the options, as seen below.
The lack of support for something similar to external entities is a known weakness of the XML Schema. Therefore there are documents that although refer to a schema they also contain a DTD declaration mainly for allowing the definition of external entities. <oXygen/> allows you to configure the validation to be performed against the specified XML schema even if a DTD is also specified thus allowing external entities and XML schema to coexist.
You can use <oXygen/> to validate an XML document instance against a specified DTD.
With <oXygen/> you can easily validate against Relax NG both in XML syntax and compact syntax and against Namespace Routing Language schemas .
The files currently selected in the Project can be validated in one action against a schema file. The supported schemas are XML Schema, Relax NG, NVDL, Schematron or XML Schema or Relax NG schema with embedded Schematron rules. This together with the logical folder support of the project allows you to group your files and validate them very easily.
The next image shows the dialog for choosing the schema.
The errors are reported by indicating the severity of the problem, location information (line number, the system identifier of the file if different from the current edited file) and a descriptive message. Tracking the errors in the document is as easy as clicking on the error in the error panel: the editor will open the file causing the error and it will highlight the location of the error.
You can control some parser settings used for validation. The features made available through <oXygen/> options are:
This turns on/off schema validation
This turns on/off full schema grammar constraint
All schema location hints will be used to locate the components for a given target namespace.
To ensure that your document gets the maximum verification, all three are turned on by default.
To associate a schema with a document you can use the "Associate schema..." action that will present a wizard to accomplish this task.
Your document will be modified to contain the schema location declaration.