Re: AW: [xml-dev] Schema validation Report Language?

XProc community group has decided to use SVRL for all validation steps, 
whatever the grammar type is (XSD, RNG/C, Schematron, nvdl). To be 
honnest, I think we won't be able to cover all validation aspects of all 
grammars, but we want to have a validation report based on the same 
grammar to simplify the XProc pipelines writing. Maybe it'll conduct us 
to use an extended SVRL...
This has been discussed in Prague : 
https://github.com/xproc/Workshop-2017-02/wiki/Minutes-for-day-one:-7-February-2017
I don't think someone in the community group has yet worked on this.

Best regards,
Christophe


Le 2017-03-08 22:49, Frank Steimke a écrit :
> 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:]
> Gesendet: Mittwoch, 8. März 2017 10:32
> An: Frank Steimke <>
> Cc: 
> 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
> Saxonica
> 
> 
>> Does 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: 
>> subscribe:  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: 
> subscribe:  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: 
> subscribe: 
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php