Hi Mike, thank you very much for your explanation. I understand that there is no general, standardized solution for our scenario. How very unfortunate. We use Saxon in our project, so your hint about the XML format for reporting validation errors is very helpful. Combined with Ricks suggestion we shall be able to get a validation report which covers XSD validation as well as Schematron validation. However, this solution will be SAXON specific. Thanks again, Frank -----Ursprüngliche Nachricht----- Von: Michael Kay [mailto:mike@saxonica.com] Gesendet: Mittwoch, 8. März 2017 10:32 An: Frank Steimke <f-steimke@berger-und-steimke.de> Cc: xml-dev@lists.xml.org Betreff: Re: [xml-dev] Schema validation Report Language? You may be aware that Saxon has an XML report format for reporting XSD validation errors (documented in a schema validation-reports.xsd in the saxon-resources download file) - use -report:filename on the com.saxonica.Validate command line to get this output. But this doesn't conform to any kind of standard, and as far as I'm aware, there isn't one.
Closely related to this question is another one: is it a requirement for every W3C Schema validation engine to report schema errors and validation failures in terms of appendix C "Outcome Tabulations" of XML Schema Part 1: Structures, together with a error location in a standardized way?
In XSD 1.1 this is appendix B, and is introduced by the paragraph: To facilitate consistent reporting of schema errors and ·validation· failures, this section tabulates and provides unique names for all the constraints listed in this document. Wherever such constraints have numbered parts, reports SHOULD use the name given below plus the part number, separated by a period ('.'). Thus for example cos-ct-extends.1.2 should be used to report a violation of the clause 1.2 of Derivation Valid (Extension) (§3.4.6.2). So it's a "should" requirement rather than a "must". And to be honest, it's rather a pain, (a) because the descriptions of the constraints are written in language that is totally incomprehensible to the typical user of a schema processor, (b) because it's very difficult to identify a specific clause when you have rules written in the form "one of the following must be true" nested several levels deep, and (c) because the logic inside the processor doesn't always align 1-1 with the rules in the spec, so at the point you detect a validation error you don't always know which rule it relates to. There's no requirement in the spec to report line numbers or any other error location. Line numbers aren't really feasible as a normative requirement because (a) there's no such concept in the Infoset (which is the official input to a schema processor), and (b) they often aren't available in practice, e.g. when the actual input is a DOM tree. Saxon tries to report either or both of line/column number (as defined in SAX) and a unique XPath to the node. Note that very often it's not the line number of the invalid element that you want, but the line number of the element that causes its parent to be invalid: if G isn't allowed as a child of F, then it's F that's invalid according to the PSVI rules, but it's the line number of G that you are interested in. Michael Kay SaxonicaDoes this also hold for relax NG engines (although i know only one ...).
Thanks in advance,
Frank Steimke
______________________________________________________________________
_
XML-DEV is a publicly archived, unmoderated list hosted by OASIS to
support XML implementation and development. To minimize spam in the
archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org List archive:
http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
_______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php