search

xspec / xspec-maven-plugin-1

XSpec Maven Plugin
BSD 3-Clause "New" or "Revised" License
5 stars 12 forks source link

expect-report not handled correctly #63

Open lueck opened 4 years ago

lueck commented 4 years ago

Hi,

the expect-report element for schematron tests is not evaluated correctly. Where the command line version of xspec behaves as expected, the plugin does not. Here is the report of the command line version of xspec first on a test I've defined:

Running Tests...
Testing with SAXON HE 9.9.1.6
Test schematron validation of the consistency of witness attributes
..report parallel use
not report witness002 //t:app[1]/t:lem[1]
report witness002 //t:app[1]/t:rdg[1]
not report witness002 //t:app[1]/t:rdg[2]
report witness002 //t:app[1]/t:rdg[3]
not report witness002 //t:app[1]/t:rdg[4]
not report witness002 //t:app[1]/t:rdg[5]
not report witness002 //t:app[1]/t:rdg[6]
not report witness002 //t:app[2]/t:lem[1]
not report witness002 //t:app[2]/t:rdg[1]
not report witness002 //t:app[2]/t:rdg[2]
report witness002 //t:app[2]/t:rdg[3]
..report use of non-registered witnesses
not report witness001 //t:app[1]/t:lem[1]
not report witness001 //t:app[1]/t:rdg[1]
not report witness001 //t:app[1]/t:rdg[2]
not report witness001 //t:app[1]/t:rdg[3]
not report witness001 //t:app[1]/t:rdg[4]
not report witness001 //t:app[1]/t:rdg[5]
not report witness001 //t:app[1]/t:rdg[6]
not report witness001 //t:app[2]/t:lem[1]
not report witness001 //t:app[2]/t:rdg[1]
report witness001 //t:app[2]/t:rdg[2]
report witness001 //t:app[2]/t:rdg[3]

Formatting Report...
passed: 22 / pending: 0 / failed: 0 / total: 22

And here is the report from the maven plugin:

Test schematron validation of the consistency of witness attributes
..report parallel use
not report witness002 //t:app[1]/t:lem[1]
report witness002 //t:app[1]/t:rdg[1]
      FAILED
not report witness002 //t:app[1]/t:rdg[2]
report witness002 //t:app[1]/t:rdg[3]
      FAILED
not report witness002 //t:app[1]/t:rdg[4]
not report witness002 //t:app[1]/t:rdg[5]
not report witness002 //t:app[1]/t:rdg[6]
not report witness002 //t:app[2]/t:lem[1]
not report witness002 //t:app[2]/t:rdg[1]
not report witness002 //t:app[2]/t:rdg[2]
report witness002 //t:app[2]/t:rdg[3]
      FAILED
..report use of non-registered witnesses
not report witness001 //t:app[1]/t:lem[1]
not report witness001 //t:app[1]/t:rdg[1]
not report witness001 //t:app[1]/t:rdg[2]
not report witness001 //t:app[1]/t:rdg[3]
not report witness001 //t:app[1]/t:rdg[4]
not report witness001 //t:app[1]/t:rdg[5]
not report witness001 //t:app[1]/t:rdg[6]
not report witness001 //t:app[2]/t:lem[1]
not report witness001 //t:app[2]/t:rdg[1]
report witness001 //t:app[2]/t:rdg[2]
      FAILED
report witness001 //t:app[2]/t:rdg[3]
      FAILED
passed: 17 / pending: 0 / failed: 5 / total: 22

The difference comes exactly from the evaluation of expect-report elements.

For reproduction, I attach the schematron file and the xspec file (with txt file suffix due to supported files).

witness.sch test_witness.xspec

Regards, Chris

AirQuick commented 4 years ago

The problem is reproduced also on v1.x of the command-line XSpec. On XSpec v1.x, x:*/@location is rather primitive; you can't use advanced XPath expressions in @location. You have to write every node in path using simple integer predicate. i.e. location="/t:TEI[1]/t:text[1]/t:body[1]/t:p[1]/t:app[1]/t:rdg[1]" instead of location="//t:app[1]/t:rdg[1]". See also xspec/xspec#1277.

The soon-to-be-released XSpec v2.0 has improved @location in xspec/xspec#1107. That's why the problem is not reproduced on the recent master branch of the command-line version.