{"id":469,"date":"2015-09-30T15:48:37","date_gmt":"2015-09-30T13:48:37","guid":{"rendered":"http:\/\/xml-buddy.com\/xmltribune\/?p=469"},"modified":"2015-09-30T22:43:18","modified_gmt":"2015-09-30T20:43:18","slug":"how-to-debug-schematron-validation","status":"publish","type":"post","link":"https:\/\/www.xml-buddy.com\/xmltribune\/how-to-debug-schematron-validation\/","title":{"rendered":"How to debug Schematron validation"},"content":{"rendered":"

A Schematron validator is a powerful tool to run business rules for your XML data and to check conditions\u00a0that are not supported using W3C schema. Schematron uses a lot of XPath and the validator is based on XSLT to apply all rules to the XML instance.<\/p>\n

But often it is not easy to debug a Schematron check\u00a0if it does\u00a0not work as expected. Because the Schematron rules\u00a0are transformed to a stylesheet to run\u00a0the validator, it is not always clear where the error happens. To make life easier in this regard, the XML ValidatorBuddy<\/a> editor supports several functions which are targeted at\u00a0the transformation from the Schematron input to the final XSLT for the validator.<\/p>\n

First step: Check the output from the Schematron pre-processing for includes and abstract rules<\/h3>\n

If the Schematron uses includes and abstract rules the pre-processor generates an intermediate schema with all of the included and abstract rules. Select the original Schematron in the built-in File Explorer and\u00a0use the “Get Schematron schema after pre-processing” command from the XML menu in the editor to get a copy of this intermediate schema saved next to your original Schematron file.<\/p>\n

\"Get<\/a>\u00a0Afterwards a new Schematron\u00a0document (usually having .sch as extension) is available in the same folder with “after_preprocess” appended to the name of the original Schematron. You can inspect this file in the editor if all of the includes and abstract rules are present. If not, please check if your include files are accessible and well-formed. For abstract rules, take a look if the “id” and “is-a” attributes are correctly used.<\/p>\n

Second step: Generate the final stylesheet for the Schematron validator<\/h3>\n

You can generate the final XSLT for the validator similar to generating the intermediate schema for the pre-process step. Again select the original Schematron in the built-in File Explorer and use the “Get Schematron validation stylesheet” from the XML menu.\u00a0Afterwards the final stylesheet for the validator\u00a0is available in the same folder with “_final.xsl” appended to the name of the original Schematron.<\/p>\n

This XSLT can be applied to the XML instance using the “Transform XSL…” command in the editor like any other stylesheet. Any errors occurred during the transformation are visible in the standard Results window in XML ValidatorBuddy<\/a>. If the XSL transformation produced some output you can check the resulting document if the Schematron validator applied your rules as expected.<\/p>\n

Use the XPath evaluator window<\/h3>\n

Schematron rules are using XPath expressions to check if a rule should trigger in the current context. The XPath evaluator in the editor helps a lot to simplify the creation of such XPath expressions. Use it to get a feeling what results a certain expression gives in the current XML context.<\/p>\n

\"XPath<\/a><\/p>\n

It is also easy to get a full qualified XPath for any selection in the editor. Just move the cursor to the XML element or attribute where you want to get the XPath and use the “Copy XPath” command either from the “Edit” or the context menu.<\/p>\n

»crosslinked«<\/b><\/a><\/sub><\/p>","protected":false},"excerpt":{"rendered":"

A Schematron validator is a powerful tool to run business rules for your XML data and to check conditions\u00a0that are not supported using W3C schema. Schematron uses a lot of XPath and the validator is based on XSLT to apply all rules to the XML instance. But often it is not easy to debug a Schematron check\u00a0if it does\u00a0not work… Read more »<\/a><\/p>\n","protected":false},"author":2,"featured_media":476,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_mi_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0},"categories":[12,1,6],"tags":[69,74],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/posts\/469"}],"collection":[{"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/comments?post=469"}],"version-history":[{"count":6,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/posts\/469\/revisions"}],"predecessor-version":[{"id":482,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/posts\/469\/revisions\/482"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/media\/476"}],"wp:attachment":[{"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/media?parent=469"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/categories?post=469"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xml-buddy.com\/xmltribune\/wp-json\/wp\/v2\/tags?post=469"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}