XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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: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
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: 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS