Oxygen XML Author plugin 13.2.0

Editing Documents | 59to the W3C XML Schema 1.0 specification or according to the W3C XML Schema 1.1 specification. This can beconfigured in Preferences.• MSXML 4.0 - Included in Oxygen XML Author plugin (Windows edition only). It is associated to XML Editor,XSD Editor and XSL Editor. It is able to validate the edited document against XML Schema, internal DTD (includedin the XML document), external DTD or a custom schema type.• MSXML.NET - Included in Oxygen XML Author plugin (Windows edition only). It is associated to XML Editor,XSD Editor and XSL Editor. It is able to validate the edited document against XML Schema, internal DTD (includedin the XML document), external DTD or a custom schema type.• XSV - Not included in Oxygen XML Author plugin . Windows and Linux distributions of XSV can be downloadedfrom http://www.cogsci.ed.ac.uk/~ht/xsv-status.html. The executable path is already configured in Oxygen XMLAuthor plugin for the [Oxygen-install-folder]/xsv installation folder. If it is installed in a different folderthe predefined executable path must be corrected in Preferences. It is associated to XML Editor and XSD Editor. Itis able to validate the edited document against XML Schema or a custom schema type.• SQC (Schema Quality Checker from IBM) - Not included in Oxygen XML Author plugin . It can be downloadedfrom here (it comes as a .zip file, at the time of this writing SQC2.2.1.zip is about 3 megabytes). The executable pathand working directory are already configured for the SQC installation directory[Oxygen-install-folder]/sqc. If it is installed in a different folder the predefined executable path andworking directory must be corrected in the Preferences page. It is associated to XSD Editor.Linked Output Messages of an External EngineValidation engines display messages in an output view at the bottom of the Oxygen XML Author plugin window. Ifsuch an output message (warning, error, fatal error, etc) spans between three to five lines of text and has the followingformat then the message is linked to a location in the validated document so that a click on the message in the outputview highlights the location of the message in an editor panel containing the file referred in the message. This behavioris similar to the linked messages generated by the default built-in validator. The format for linked messages is:• Type:[F|E|W] (the string Type: followed by a letter for the type of the message: fatal error, error, warning) - this lineis optional in a linked message.• SystemID: a system ID of a file (the string SystemID: followed by the system ID of the file that will be opened forhighlighting when the message is clicked in the output message - usually the validated file, the schema file or anincluded file).• Line: a line number (the string Line: followed by the number of the line that will be highlighted).• Column: a column number (the string Column: followed by the number of the column where the highlight will starton the highlighted line) - this line is optional in a linked message.• Description: message content (the string Description: followed by the content of the message that will be displayedin the output view).Validation ScenarioA complex XML document is usually split in smaller interrelated modules which do not make much sense individuallyand which cannot be validated in isolation due to interdependencies with the other modules. A mechanism is needed toset the main module of the document which in fact must be validated when an imported module needs to be checkedfor 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 bychunk-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 toparameters and templates used but undefined which are only caused by ignoring the context in which this module isused in real XSLT transformations and in which it should be validated. To properly validate such a module, a validationscenario 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 wouldbe issued by transformation.