XML Validation and Well-Formedness Check

XML Well-Formedness Check

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.

Validate Documents

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.

Validate XML Documents Against W3C XML Schemas

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

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.

Working with Modules

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.

Let's take another example. 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 when included or imported from other files. For instance one can write an XSLT stylesheet that makes a reference to a named template or to a variable that is not defined in the current file but it is defined in a file that includes or imports that XSLT stylesheet. In that case if you check the XSLT module for validity you will get an error that there is no such template with that name or that the referred variable is not declared. However if you validate the master XSLT stylesheet that refers to this module than that is valid. <oXygen/> validation scenarios allow to specify that not the module should be validated but instead the master file that refers that module, thus validating the XSLT module in context.

Multiple Validations in One Action

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.

Working with Modules and Multiple Validation

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.

Continuous Validation

<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.

Error Markers and Overview Ruler

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.

Multiple External Validation Engines

<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.

Schematron Support

<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.

Editing ISO Schematron Schemas

<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.

Editing Support for Embedded ISO Schematron Rules in XML Schema

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.

Validating XML Documents Against ISO Schematron

The validation support from <oXygen/> handles validation against ISO Schematron schemas. This includes validation on request, continuous validation and batch validation.

Validating XML Document Against ISO Schematron embedded rules

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.

Support for Abstract Patterns and Included ISO Schematron 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.

Schematron diagnostics and reports

The diagnostics messages issued by a Schematron schema are displayed together with the other validation errors. Schematron report messages are treated as warnings.

Option for using Saxon EE (Schema Aware) for Schematron

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/>.

Allow foreign elements in an ISO Schematron schema

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.

XML Catalog Support

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.

Validate with XML Schema while Allowing External Entities

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.

Validate XML Documents Against DTDs

You can use <oXygen/> to validate an XML document instance against a specified DTD.

Validate XML Documents Against Relax NG Schema

With <oXygen/> you can easily validate against Relax NG both in XML syntax and compact syntax and against Namespace Routing Language schemas .

Extended Batch Validation

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, NRL, 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.

Error Reporting and Error Tracking

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.

Control the XML Parser Features

You can control some parser settings used for validation. The features made available through <oXygen/> options are:

• http://apache.org/xml/features/validation/schema

  This turns on/off schema validation

• http://apache.org/xml/features/validation/schema-full-checking

  This turns on/off full schema grammar constraint

• http://apache.org/xml/features/validation/honour-all-schemaLocations

  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.

Wizard for Schema Association

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.