Support Ant error levels

[stefan-jung]

Unfortunately error levels are not supported, see #16. I've changed the <report> level to warning, so the build should throw a warning and no error and should not fail. Builds should fail only on fatal or error.

Current output

[schematron] Validating XML file '/tmp/temp20170816172804143/topic-1.dita' against Schematron rules from 'topic-validation.sch' expecting success
[schematron] 1 Schematron errors for XML file '/tmp/temp20170816172804143/topic-1.dita'
[schematron] [error] in /topic/title @ /tmp/temp20170816172804143/topic-1.dita 
[schematron]                 Do not use inline formatting in <title>
[schematron]              Test=*[contains(@class, 'hi-d/')]

It would be nice, if the output would be one line per <report>/<assert>. This would make it easier to implement a log parser/filter. I'd recommend (as a replacement for the snippet above):

[schematron] /tmp/temp20170816172804143/topic-1.dita:4: [WARNING]: Do not use inline formatting in <title>

Note: The :4 shout mean line 4. I think the line is important to find the position of the error quickly. The test that fired the report/assert is not important, I think.

[phax]

I followed your suggested, trimed stuff and added error handling support. But unfortunately the source XML position cannot be emitted, because it is not part of the created SVRL

[stefan-jung]

Hmm... that's a pity. 😞
Should I add line support as a new enhancement issue? If you use Schematron for validating DITA-XML, so to check style guide rules, the line is absolutely mandatory to find the violating snippet.

The library used in oXygen XML is able to determine the line:

System-ID: /home/stefan/workspace/org.doctales.schematron/samples/topic-1.dita
Haupt-Validierungsdatei: /home/stefan/workspace/org.doctales.schematron/samples/topic-1.dita
Schema: /home/stefan/workspace/org.doctales.schematron/rules/topic-validation.sch
Programmname: ISO Schematron
Fehlerlevel: warning
Beschreibung: Do not use inline formatting in <title>
Anfang: 4:0

So if you're stuck somewhere and just need food for thought, maybe dropping a line to them might help. They'll surely strongly appreciate your work.

[phax]

I will dig into the Locator API and see what I can do...

[stefan-jung]

The log looks much better now:
https://travis-ci.org/doctales/org.doctales.schematron/builds/267180664#L702

[phax]

Haha - weird side effects :)
I was thinking more like:

if (byte stream used) then
{

1. XML Charset detection via new class https://github.com/phax/ph-commons/blob/master/ph-xml/src/main/java/com/helger/xml/serialize/read/XMLCharsetDeterminator.java
2. Instantiating a special Reader that uses the charset from step 1. and includes line counting (with the problem that the Locator is only updated AFTER something was read)
3. Enforce all DOM reading to use SAX reading with the Locator (or Locator2) based on the position of the Reader in step 2

}

-> if this helps as well - I'm happy :)

[fviolette]

Defintiely +1 on level support: would further improve the lib usage via ANT, dramatically.

[phax]

Level support is already in

[fviolette]

Right, I can see the error level in the logs. Alluding to the original request of making builds fail only on fatal or error.

[stefan-jung]

Thanks for the new release @phax!

Log levels still do not work as expected.

Schematron

<?xml version="1.0" encoding="UTF-8"?>
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt">
    <sch:pattern>
        <sch:rule context="*[contains(@class, 'topic/title')]">
            <sch:report test="*[contains(@class, 'hi-d/')]" role="warning">
                Do not use inline formatting in &lt;title&gt;
            </sch:report>
        </sch:rule>
    </sch:pattern>
</sch:schema>

This should create a warning, but leads to an error:

  [error] in /topic/title @ /tmp/temp20180103183533704/faf922d8f51b3838f7fbdbae96dd1460d7fac5ae.dita Do not use inline formatting in <title>

See build #31

Then the build crashes and this should not happen for warnings.

[phax]

Thanks for testing. I needed to get 5.0 out because of other dependencies - that's why I postponed this to 5.1 :(

[fviolette]

I was confused by the addition of the failOnError parameter initially, thanks for the reminder!
This is indeed required to create better reports and not have to artificially create phases.

[phax]

I looked a bit into it and I'm currently only interpreting the flag attribute but not the role attribute. I will make a change that will take the role attribute if the flag attribute is not present

[stefan-jung]

Excellent 😃

[phax]

See also https://www.oxygenxml.com/pipermail/oxygen-user/2009-November/002902.html

[phax]

v5.0.2 SNAPSHOT 17 and later should do the trick: https://oss.sonatype.org/content/repositories/snapshots/com/helger/ph-schematron/5.0.2-SNAPSHOT/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[phax]

@xephon2 if you could crosscheck, it would be appreicated :)

[stefan-jung]

@phax, will try to do so.

[stefan-jung]

As the log shows, nothing has changed.

• Tried latest stable release of ph-schematron 5.0.10.
• Warnings are not echoed as shown in the log.
• Build does not fail, but property has been set correctly.

[phax]

Thank you @xephon2 for your input.

• I think I resolved the issue with the missing log output - now all SVRL results are logged
• Concerning the build not failing, there is a slight misunderstanding I assume. I currently only support the property failOnError but nothing else. And this property applies not just to SVRL results but also to other criticial issues (e.g. IO errors). If I understand you correctly, you need something to break your build only depending on the validation output (SVRL).
  The following example assumes you expect a successful validation. So if an error is in SVRL and "fail on error" is true, the build should be aborted. If The SVRL contains at least one warning and "fail on warning" is true, the build should be aborted etc. Is this assumption correct? In that case I would need to create new properties like failOnSVRLError, failOnSVRLWarning and failOnSVRLInfo - does that sound reasonable?

[phax]

Finally fixed in 5.0.11