Expected Behavior

The validator generates an appropriate report in the case of a malformed xml input file

Actual Behavior

The respective instance of de.kosit.validationtool.api.Result returns null for result.getReport()
and throws a NullPointerException for result.getReportDocument().

Examples

Any non xml document suffices as input.
Then

Result report = kositValidator.checkInput(input);
report.getReportDocument() 

throws NPE

Verweis auf #45

NullPointerException beim RelativeUriResolver wenn innerhalb eines XSL die Funktion unparsed-text() verwendet wird.

Minimal-Variante der scenarios.xml
validator-configuration-xrechnung_issue#45.zip

Logdatei vom Validator:
validator.log

Genutzte Versionen:

• validationtool-1.2.0
• validator-configuration-xrechnung_1.2.2_2019-12-30

Fehler lässt sich jederzeit mit der beigefügten Konfiguration reproduzieren.

• Make explicit in Documentation

• and in code somehow like this example:

log.info("Force usage of oracle xml implementation");
// DOM-Implementation
System.setProperty("org.w3c.dom.DOMImplementationSourceList",
"com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl");
// SchemaFactory
System.setProperty(SchemaFactory.class.getName() + ":" + XMLConstants.W3C_XML_SCHEMA_NS_URI,
"com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory");
// DocumentBuilderFactory
System.setProperty(DocumentBuilderFactory.class.getName(), "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
// TransformerFactory
System.setProperty(TransformerFactory.class.getName(), "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl");

Class de.kosit.validationtool.impl.tasks.CreateReportAction uses a DOMDestination instead of the built in Saxon tree model. Same holds for input and output for de.kosit.validationtool.cmd.ExtractHtmlContentAction.

When running mvn verify with OpenJDK 8, it eventually fails when running the jacoco-maven-plugin:

[...]
[INFO] --- build-helper-maven-plugin:3.1.0:reserve-network-port (reserve-network-port) @ validationtool ---
[INFO] Reserved port 58994 for validator.server.port
[INFO] Reserved port 58995 for jacoco.tcp.port
[...]
[INFO] --- jacoco-maven-plugin:0.8.5:dump (dump) @ validationtool ---
[INFO] Connecting to localhost/127.0.0.1:58995
[INFO] Connection refused (Connection refused)
[...]

The daemon produces a 200 status code response when no scenario matches. This is unexpected. According to the documentation 200 means the validation was successful.

Edit: Actually, I also get a 200 response code if a scenario matches and the validation fails.

Wie ist Ihr Vorgehen für die Kompatibilität bei zwei unterschiedlichen XRechnungs-Versionen. Durch die Separierung zwischen Validator und Konfiguration wäre es ja grundsätzlich möglich verschiedene Versionen der XRechnung zu validieren, um so z.b. für einen Übergangszeitraum zwei Versionen der XRechnung validieren zu können.

Wird es grundsätzlich unterstütz / berücksichtigt, dass man mit der aktuellen Validator-Version die aktuelle und mind. die vorherige XRechnungs-Konfiguration nutzen kann oder kann es hierbei ggf. Breaking-Changes geben, so das ggf. auch ein älterer Validator für die vorherige XRechnungs-Konfiguration notwendig wäre?

Oder gehen Sie grundsätzlich davon aus, dass durch die Definition des Gültigkeitszeitraumen in der Spezifikation der XRechnung der Wechsel "hart" zum definierten Termin erfolgen wird/muss und damit ältere Versionen prinzipiell nicht mehr unterstützt werden und somit diese Kompatibilität gar nicht berücksichtigt wird/werden muss?

I think the implmentation of rule CL01 for the document type code ist wrong.
The Test test="((not(contains(normalize-space(.), ' 80 81 82 83 84 130 202 203 204 211 261 262 295 296 308 325 326 380 381 383 384 385 386 387 388 389 390 393 394 395 396 420 456 457 458 527 575 623 633 751 780 935 ')) and contains(' ', concat(' ', normalize-space(.), ' '))))" does not allow for example the value 380 (commerial invoice).
The test should be test="((not(contains(normalize-space(.), ' ')) and contains(' 80 81 82 83 84 130 202 203 204 211 261 262 295 296 308 325 326 380 381 383 384 385 386 387 388 389 390 393 394 395 396 420 456 457 458 527 575 623 633 751 780 935 ', concat(' ', normalize-space(.), ' '))))" (the same structure as for e,g, CL-03, CL-04, ...

Observed behaviour

When calling the validator's checkInput() method using a document that doesn't have a valid XML body (for instance, plain text), the method call will result in the validator crashing with a java.lang.NullPointerException.

Expected behaviour

The validator does not throw an Exception but returns a Result object instead, indicating that the provided document does not contain valid/well-formed XML.

Additional information

• validator version: 1.1.0
• Java version: 1.8

Method call

validator is called as follows:

public void validate(byte[] documentToValidate) {
    Input document = InputFactory.read(documentToValidate, "xRechnung");
    lastResult = validator.checkInput(document);
}

Test file content

The exception was encountered with any type of file content that did not contain any XML tags (a regular text file for instance).

Stack trace

java.lang.NullPointerException
	at de.kosit.validationtool.impl.tasks.CreateReportAction.getTransformation(CreateReportAction.java:96)
	at de.kosit.validationtool.impl.tasks.CreateReportAction.check(CreateReportAction.java:76)
	at de.kosit.validationtool.impl.DefaultCheck.runCheckInternal(DefaultCheck.java:117)
	at de.kosit.validationtool.impl.DefaultCheck.checkInput(DefaultCheck.java:108)

Validator log

INFO    2019-09-18 15:40:35,623 [main] de.kosit.validationtool.api.CheckConfiguration  - Creating default scenario repository (alongside scenario definition)
INFO    2019-09-18 15:40:35,724 [main] de.kosit.validationtool.impl.ScenarioRepository  - Loading scenarios from file:/xxxxxxxxxxxxx/target/classes/xRechnung_v120/scenarios.xml
INFO    2019-09-18 15:40:35,725 [main] de.kosit.validationtool.impl.ContentRepository  - Load schema from source file:/xxxxxxxxxxxxx/de/kosit/validationtool/1.1.0/validationtool-1.1.0.jar!/xsd/scenarios.xsd
INFO    2019-09-18 15:40:35,995 [main] de.kosit.validationtool.impl.ScenarioRepository  - Loaded scenarios for Prüftool-Konfiguration XRechnung 1.2.0 by KoSIT from 2018-12-19. The following scenarios are available:

EN16931 CIUS XRechnung (UBL Invoice)
EN16931 CIUS XRechnung (UBL CreditNote)
EN16931 CIUS XRechnung (CII)

INFO    2019-09-18 15:40:35,995 [main] de.kosit.validationtool.impl.ScenarioRepository  - Loading scenario content from file:/xxxxxxxxxxxxx/target/classes/xRechnung_v120/
INFO    2019-09-18 15:40:36,671 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/ubl/2.1/xsl/EN16931-UBL-validation.xsl
INFO    2019-09-18 15:40:37,803 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/xrechnung/1.2.0/xsl/XRechnung-UBL-validation-Invoice.xsl
INFO    2019-09-18 15:40:37,858 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/xrechnung-report.xsl
INFO    2019-09-18 15:40:38,075 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/ubl/2.1/xsl/EN16931-UBL-validation.xsl
INFO    2019-09-18 15:40:38,869 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/xrechnung/1.2.0/xsl/XRechnung-UBL-validation-CreditNote.xsl
INFO    2019-09-18 15:40:38,907 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/xrechnung-report.xsl
INFO    2019-09-18 15:40:38,987 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/cii/16b/xsl/EN16931-CII-validation.xsl
INFO    2019-09-18 15:40:39,352 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/xrechnung/1.2.0/xsl/XRechnung-CII-validation.xsl
INFO    2019-09-18 15:40:39,376 [main] de.kosit.validationtool.impl.ContentRepository  - Loading XSLT script from  resources/xrechnung-report.xsl
INFO    2019-09-18 15:40:39,440 [main] de.kosit.validationtool.impl.DefaultCheck  - Checking content of xRechnung
INFO    2019-09-18 15:40:39,440 [main] de.kosit.validationtool.impl.DefaultCheck  - Step DefaultCheck$$Lambda$264/1295356732 finished in 0ms
Error on line 1 column 1 
  SXXP0003: Error reported by XML parser: Content ist nicht zulässig in Prolog.
INFO    2019-09-18 15:40:39,447 [main] de.kosit.validationtool.impl.tasks.DocumentParseAction  - Parsing war nicht erfolgreich: null -> [IOException while reading resource xRechnung: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content ist nicht zulässig in Prolog. At row null at pos null]
INFO    2019-09-18 15:40:39,448 [main] de.kosit.validationtool.impl.DefaultCheck  - Step DocumentParseAction finished in 8ms
INFO    2019-09-18 15:40:39,448 [main] de.kosit.validationtool.impl.DefaultCheck  - Step ScenarioSelectionAction finished in 0ms
INFO    2019-09-18 15:40:39,448 [main] de.kosit.validationtool.impl.DefaultCheck  - Step SchemaValidationAction finished in 0ms
INFO    2019-09-18 15:40:39,448 [main] de.kosit.validationtool.impl.DefaultCheck  - Step SchematronValidationAction finished in 0ms
INFO    2019-09-18 15:40:39,593 [main] de.kosit.validationtool.impl.DefaultCheck  - Step ValidateReportInputAction finished in 145ms

Validating the (incorrect) instance 01.10a-INVOICE_ubl.zip leads to a Type error in XSL which in turn leads to an error in the Validationtool:

[main] INFO de.kosit.validationtool.impl.DefaultCheck - Checking content of instances\01.10a-INVOICE_ubl.xml
Type error at char 40 in xsl:when/@test on line 276 column 620 of XRechnung-UBL-validation-Invoice.xsl:
XPTY0004: A sequence of more than one item is not allowed as the first argument of
tokenize() ("#SKONTO#TAGE=7#PROZENT=2.00#", "#SKONTO#TAGE=14#PROZENT=1.00#", ...)
in built-in template rule at xsl:apply-templates (file:/C:/Users/Mirco/Desktop/xrechnung-1_1-20171219%20(1)/xrechnung/resources/xrechnung/ubl21/xsl/XRechnung-UBL-validation-Invoice.xsl#199)
processing /
[main] ERROR de.kosit.validationtool.cmd.CommandLineApplication - Can not run schematron validation

Despite the Type error, the Validationtool should continue and generate a validation report.

The id in rep:message should be unique.
Scheme: assertion-id "." local-id

At the moment, local-id is always 1.

Problem is in default-report.xsl:

count(preceding-sibling::failed-assert | preceding-sibling::successful-report) + 1)

misses namespace prefix svrl.

i want to run the daemon inside a docker container to validate XRechnung. my dockerfile looks like

FROM openjdk:16-slim

# Setup needed programs
RUN apt-get update
RUN apt-get install unzip wget -y
#RUN git clone https://github.com/itplr-kosit/validator.git ./validator
#RUN cd ./validator && git checkout tags/v1.4.0
#RUN cd ./validator && ls -l

# Download Validator and unzip
RUN wget https://github.com/itplr-kosit/validator/releases/download/v1.4.0/validationtool-1.4.0.zip -O validator.zip
RUN unzip validator.zip -d validator
RUN ls -l
RUN cd ./validator && ls -l

RUN wget https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/release-2020-07-31/validator-configuration-xrechnung_2.0.0_2020-07-31.zip -O validator-configuration.zip
RUN unzip validator-configuration.zip -d validator-configuration
RUN ls -l
RUN cd ./validator-configuration && ls -l

#RUN java -version

EXPOSE 80
EXPOSE 8080

CMD ["java", "-jar", "./validator/validationtool-1.4.0-standalone.jar", "-s", "./validator-configuration/scenarios.xml", "-D", "-P", "8080"]

i build the image with docker build -t daemon_test . and start the container with docker run --rm --network "host" daemon_test.

the daemon starts up fine and is showing me that XRechnung-scenarios are available.

KoSIT Validator version 1.4.0
Loading scenarios from  file:///./validator-configuration/scenarios.xml
Using repository  null
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/validator/validationtool-1.4.0-standalone.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/validator/validationtool-1.4.0-standalone.jar) to method java.lang.ClassLoader.resolveClass(java.lang.Class)
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/validator/validationtool-1.4.0-standalone.jar) to method java.lang.ClassLoader.findLoadedClass(java.lang.String)
Loaded "Validator Configuration XRechnung 2.0.0" by Coordination Office for IT Standards (KoSIT) from 2020-08-06

The following scenarios are available:
  * EN16931 XRechnung (UBL Invoice)
  * EN16931 XRechnung (UBL CreditNote)
  * EN16931 XRechnung (CII)
  * EN16931 (UBL Invoice)
  * EN16931 (UBL CreditNote)
  * EN16931 (CII)

Starting daemon mode ...
Daemon started. Visit http://localhost:8080

but i can't reach the daemon. i can't even see the gui.
what i would like to know: is there an error in calling the daemon command? any incompatibility with the base image or some other obvious failure?

Issue
When using the latest release of validator with this release of its configuration, when accessing the Result object after validating an xRechnung, its acceptRecommendation will be UNDEFINED, even for Schematron violations.

Examination
Looking at the code responsible for determining the accept recommendation it becomes obvious that the value depends on the acceptMatch element defined in scenarios.xml. Using the scenario file and schema from this project though, the element cannot be set as the schema supposedly has been upgraded with the latest release (see upgraded version in validator project).

Conclusion
It seems as if the scenario file/schema definition is deprecated as of version 1.1.0 of the validator. Which configuration is the one to use? Are other parts of the configuration affected by the latest release as well?

When creating a new DefaultCheck from a CheckConfiguration, Validator release v1.1.0 throws a FileNotFoundException, apparently because it is unable to load the schema files listed in scenarios.xml. The behaviour is very similar to this Issue. I can also confirm that the validator works fine in a Spring Boot standalone fat jar, however our setup looks slightly different, resulting in a failing startup sequence:

• Application Server: IBM WebSphere Liberty 18.0.0.1, also tested with IBM WebSphere Application Server 9
• Application Framework: Spring with Spring-WS
• Packaging structure: Application Packaged as an ear, with the following structure:

EAR Archive
|   kositvalidator-api.war
|
+---lib
|       kositvalidator-logic-0.0.1.0.jar
|       validationtool-1.1.0.jar

Our code initializing the validator, including its scenarios.xml and xsd files reside in the kositvalidator-logic*.jar. More information on the package structure can be found in the attached gist.

Details/ additional information
All information on how we call the Validator, as well as log files and the exact EAR package structure can be found in this gist.

Thanks a lot for any helpful advice!

Within the CII Schematron rules on code list values there are no assert ID existent. Within a report the failed assert of this rules are diplayed with the value of its flag instead of displaying an emty field.

Standards like XRechnung want to be able to check for the file encoding of XML files. Consider implementing this is as an optional/customizable feature which can be configured in scenarios.xml and or via CLI flags.

Hey there, always getting the error:
BR-S-08-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is "Standard rated" and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119).
For every xRechnung 1.2 and xRechnung 2.0 that i created.
Although the price amounts etc. are perfectly matching.
Same invoice, same values etc. is validating fine with the zugferd profiles.
This only happens when validating xRechnung, here with the validator or any other validator on the net.
Maybe someone could give me and hand, and check the invoice and give me a little hint why that is?
Can i get any help on this from anyone?

In order to be able to validate ZUGFeRD 2 and Factur-X against the XRechnung CIUS I suggest that your InputFactory checks if it just received a ZF file, and extracts it's XML if that is the case.

Requirements are

• the PDF files might be internally compressed
• the embedded file name may be ZUGFeRD-invoice.xml for zf1, zugferd-invoice.xml for zf2 or factur-x.xml for fx
• (use the real filenames, not just the keys in the dictionary) and
• the XML files might be embedded in "flat" or "array" notation as well

First of all, thanks for this awesome project!

I think I found a bug in the scenarios.xml processing. The following works:

    <namespace prefix="ram">urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100</namespace>

However, the following results in a mismatch:

    <namespace prefix="ram">urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100
    </namespace>

I guess the element content needs trimming. I haven't tested where else in the XML this would break.

At the moment a validation scenario must be configured via a scenario.xml file together with a multiple xsl and other configuration files. However most users of this library would probably prefer if everything they need would be included in a jar file and could be configured via the java api. I would propose something like this as the first possibility to set up a scenario (in addition to the old style via a scenario.xml):

    CheckConfiguration config = new CheckConfiguration(DefaultScenarios.xRechnung);
    Check validator = new DefaultCheck(config);

This should essentially be equal to the validator-configuration-xrechnung repository.
If one needs more flexibility something like this should be included as the second possibility:

    Scenario scenario = new Scenario();
    scenario.setValidators(DefaultValidator.xRechnungCII, DefaultValidator.xRechnungUBL, Validator.fromXsl(somePath))
    scenario.setReport(DefaultReport.xRechnung)
    // or 
    scenario.setReport(Report.fromXsd(someOtherPath))

    CheckConfiguration config = new CheckConfiguration(scenario);
    Check validator = new DefaultCheck(config);

The try catch block includes to method calls where always both have to be executed. However, in case first method fails the second call will never be executed.

public static SchemaFactory createSchemaFactory() {
    SchemaFactory sf = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
    try {
        sf.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
        sf.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "file");
    } catch (SAXException e) {
        log.warn("Can not disable external DTD access, maybe an unsupported JAXP implementation is used", e);
    }
    return sf;
}

Solution: separate in two try catch blocks.

Some Links in README.md are broken
Fix with PR #31

Die Prüfung

<xsl:when test="(ram:GrandTotalAmount = round( ram:TaxBasisTotalAmount*100 + ram:TaxTotalAmount[@currencyID=/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode]*100 +0) div 100) or ((ram:GrandTotalAmount = ram:TaxBasisTotalAmount) and not (ram:TaxTotalAmount[@currencyID=/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode]))"/>

[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).

Macht es notwendig, dass die currencyID in TaxTotalAmount der SpecifiedTradeSettlementHeaderMonetarySummation angegeben wird. Ist das wirklich gewünscht? scheinbar ist das die einzige Stelle bei der eine currencyID erforderlich ist. An anderen Stellen ist das untersagt.

Hallo,

eine XRechnung (2.0) mit dem Validator zu validieren funktioniert. XML wird nicht "beanstandet".
Eine PDF/A3 mit einer einbetteten XRechnung (2.0) zu validieren, endet mit folgender Exception:

2020-12-09 14:55:00,094 [main] INFO  de.kosit.validationtool.impl.DefaultCheck - Checking content of Invoice2020
Error on line 1 column 1 of Invoice2020:
  SXXP0003: Error reported by XML parser: Content ist nicht zulässig in Prolog.
2020-12-09 14:55:07,350 [main] DEBUG de.kosit.validationtool.impl.tasks.DocumentParseAction - Exception while parsing Invoice2020
net.sf.saxon.s9api.SaxonApiException: org.xml.sax.SAXParseException; systemId: file:///C:/Projekte/zugferd/Invoice2020; lineNumber: 1; columnNumber: 1; Content ist nicht zulässig in Prolog.
	at net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:360)
	at de.kosit.validationtool.impl.tasks.DocumentParseAction.parseDocument(DocumentParseAction.java:70)
	at de.kosit.validationtool.impl.tasks.DocumentParseAction.check(DocumentParseAction.java:90)
	at de.kosit.validationtool.impl.DefaultCheck.runCheckInternal(DefaultCheck.java:118)
	at de.kosit.validationtool.impl.DefaultCheck.checkInput(DefaultCheck.java:109)
	at de.euroimmun.server.validation.ConfigurableValidation.getResult(ConfigurableValidation.java:104)
	at de.euroimmun.server.validation.ConfigurableValidation.validate(ConfigurableValidation.java:65)
	at de.euroimmun.server.validation.ConfigurableValidationTest.testPDFValidation(ConfigurableValidationTest.java:36)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:220)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:53)
Caused by: net.sf.saxon.trans.XPathException: org.xml.sax.SAXParseException; systemId: file:///C:/Projekte/zugferd/Invoice2020; lineNumber: 1; columnNumber: 1; Content ist nicht zulässig in Prolog.
	at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:455)
	at net.sf.saxon.event.Sender.send(Sender.java:167)
	at net.sf.saxon.Configuration.buildDocumentTree(Configuration.java:4236)
	at net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:357)
	... 32 more
Caused by: org.xml.sax.SAXParseException; systemId: file:///C:/Projekte/zugferd/Invoice2020; lineNumber: 1; columnNumber: 1; Content ist nicht zulässig in Prolog.
	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1472)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:994)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
	at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:435)
	... 35 more

Bin leider noch nicht dahinter gekommen, was genau mit "Content ist nicht zulässig in Prolog." beanstandet wird.
Eine Idee was da genau beanstandet wird ???

In der Klasse StrictRelativeResolvingStrategy passiert folgendens:

        // grundsätzlich Feature-konfiguration:
        processor.setConfigurationProperty(Feature.DTD_VALIDATION, false);
        processor.setConfigurationProperty(Feature.ENTITY_RESOLVER_CLASS, "");
        processor.setConfigurationProperty(Feature.XINCLUDE, false);
        processor.setConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS, false);

Die Signatur der Methode ist folgende void setConfigurationProperty(String name, Object value).
Der Methode wird aber Feature<Boolean>, boolean übergeben, was zu einem Problem führt.
Saxon-HE 9.9.1-7 setze ich auch ein.

Hier die Exception:

java.lang.NoSuchMethodError: net.sf.saxon.s9api.Processor.setConfigurationProperty(Lnet/sf/saxon/lib/Feature;Ljava/lang/Object;)V

	at de.kosit.validationtool.impl.xml.StrictRelativeResolvingStrategy.createProcessor(StrictRelativeResolvingStrategy.java:106)
	at de.kosit.validationtool.impl.xml.BaseResolvingStrategy.getProcessor(BaseResolvingStrategy.java:52)
	at de.kosit.validationtool.config.ConfigurationLoader.build(ConfigurationLoader.java:136)

If I pass an invoice to the Validator (v1.3.1), whose file name does not contain a dot, the reports are generated with the expected filenames -report.html and -report.xml. E.g. the invoice "C:\Xrechnung\Export\Invoice\abc.xml", executed via

java -jar "C:\Xrechnung\Kosit\lib\validationtool-1.3.1-standalone.jar" -s "C:\Xrechnung\Kosit\xrechnung\conf\scenarios.xml" -r "C:\Xrechnung\Kosit\xrechnung\conf" -h -o "C:\Xrechnung\Export\Bericht" "C:\Xrechnung\Export\Rechnung\abc.xml"

generated the following reports: "abc-report.html" and "abc-report.xml"

However, if the file name of the invoice contains a dot, e.g. "abc.123.xml", and you call the Validator as above, you will get the reports "abc.123-report.html" and "abc-report.123". The name of the HTML report looks quite good so far, but the suffix "-report" is moved before dot and the file extension is discarded, so that only what was previously behind the dot, stays there as the file extension.

If you use the project as API, the scenarios and all xslt are read in at each validation. This is very costly in terms of performance. Would it be possible to implement a caching? I could also do a PR for it.

When i try to run the given example i get this exception:

Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at de.kosit.validationtool.impl.DefaultCheck.(DefaultCheck.java:73)
at de.kosit.validationtool.cmd.InternalCheck.(InternalCheck.java:48)
at de.kosit.validationtool.cmd.CommandLineApplication.processActions(CommandLineApplication.java:135)
at de.kosit.validationtool.cmd.CommandLineApplication.mainProgram(CommandLineApplication.java:105)
at de.kosit.validationtool.cmd.CommandLineApplication.main(CommandLineApplication.java:85)

I need to add "--add-modules java.xml.bind" like the following to make it run:

java --add-modules java.xml.bind -jar validationtool-1.0.1-standalone.jar -s scenarios.xml invoice.xml

It would be nice if that was mentioned somehow in the documentation.

I suppose this comment should be in an <xs:annotation><xs:documentation> element.

In de/kosit/validationtool/api/InputFactory:154 the supplied input stream is written into memory as ByteArrayOutputStream. It is possible that xRechnungen are arbitrarily large as they contain embedded files. It would be advantageous if the validation tool would perform its operations directly on the stream without completely writing it into memory. This should be supported by saxon.

Please provide maven artifacts in any maven repo for validationtool and configuration. Can be combined with this FR: #33

If I want to integrate the validationtool I have to check it out and create an artifact on my own. Thats not difficult, but a separate Task Todo. For integration it would be easier to use an dependency with maven oder gradle.

There is sometimes the use case that third parties want to include validator and a configuration with in there application and package both as a jar.

For several reasons, we do not support this well, yet. However, it is a useful feature.

Guten Tag,

ich versuche das Validationtool in meine Anwendung zu nutzen und habe da einige Probleme.

Könnt Ihr mir hier weiterhelfen?

Danke.

Wenn ich Ihr einfaches Beispiel von https://github.com/itplr-kosit/validator/blob/master/docs/api.md nehme, bekomme ich immer:
Cannot cast object 'de.kosit.validationtool.config.ConfigurationLoader@475d59c0' with class 'de.kosit.validationtool.config.ConfigurationLoader' to class 'de.kosit.validationtool.api.Configuration'

Code:

URL scenarios = this.getClass().getClassLoader().getResource("scenarios.xml")
Configuration config = Configuration.load(scenarios.toURI())
Check validator = new DefaultCheck(config);

Alternative habe ich folgendes benutzt:

URL scenarios = this.getClass().getClassLoader().getResource("scenarios.xml")
Configuration config = Configuration.load(scenarios.toURI()).setResolvingMode(ResolvingMode.STRICT_LOCAL)
                .build();

Ich bekomme dann:
Can not disable external DTD access. Maybe an unsupported JAXP implementation is used.

At the moment the return type of defaultCheck.check is Document, which is a representation of the xml report. For a developer it is now non obvious whether the xRechnung was invalid and should be rejected or valid and can be forwarded. It follows a non complete list of useful methods for a better return object.

boolean isAcceptRecommendation()
Document getReport()
String or DOM etc. getReportAsHtml()
List getValidationResult(): list of all validation steps with their result

Issue
I just updated the validator to the newest version and discovered another behaviour in compare to previous version while validating an XRechnung which contain a not valid start date. (In release notes I can only find informations about bugfixes, not about changing the validation behaviour.)

Scenario
When validating an XRechnung with:

<cac:InvoicePeriod>
    <cbc:StartDate>Gestern</cbc:StartDate>
    <cbc:EndDate>2016-12-31+01:00</cbc:EndDate>
</cac:InvoicePeriod>

I get this exception:

Error evaluating (fn:exists(...) and fn:exists(...) and xs:date(EndDate) ge xs:date(StartDate) or fn:empty(...) or fn:empty(...)) in xsl:when/@test on line 2036 column 188 of EN16931-UBL-validation.xsl:
FORG0001: Invalid date "Gestern" (Non-numeric year component)
java.lang.IllegalStateException: Can not run schematron validation

... and validation is not successful. When validating the same XRechnung with version 1.1.0 of the validator no exceptions are thrown and a result object is returned with following schema violations:

cvc-datatype-valid.1.2.1: 'Gestern' ist kein gültiger Wert für 'date'.
cvc-complex-type.2.2: Element 'cbc:StartDate' darf kein Element [untergeordnete Elemente] haben, und der Wert muss gültig sein.

Question
I would expect that the result of the validation should be the same or at least no exception should be thrown. Can you please say if this behaviour has been intentionally changed or if it is just some kind of bug?

Additional Information
Versions in usage:
validationtool-1.1.2.jar
validator-configuration-xrechnung_1.2.2_2019-12-30.zip
Java(TM) SE Runtime Environment (build 1.8.0_241-b07)

I integrated your validationtool in our product. When validating the example from xrechnung-testsuite

https://github.com/itplr-kosit/xrechnung-testsuite/blob/master/instances/01.01a-INVOICE_ubl.xml

all seems o.k.

The generated Report shows no errors,

Return values From Report-Object:

.isProcessingSuccessful() ==> true
.isSchemaValid(); ==> true
.isWellformed(); ===> true

but

isAcceptable() ==> false

but in the "Prüfbericht", there is the sentence:

Bewertung: Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten.

(same report Result, if I run it from command-line)

What should I do? Could I ignore the isAcceptable or is this a bug?

When processing multiple larger input files (> 10m), processing gets slower and slower with each file and finally runs into an out of memory exception.

That should not be the case, as there should be no need to keep any significant amount of data of a previous input or output when processing the next one.

Original stdout:

D:\pk32_test\pk32\Ci\sv>run10mxmx512mall

D:\pk32_test\pk32\Ci\sv>"d:\pk32_test\pk32\CI\bin\java.exe" -classpath bin -Xmx512M -jar d:/pk32_test/pk32/CI/sv/lib/validationtool-1.0.1-standalone.jar -s D:/pk32_test/pk32/Ci/sv/scenarios.xml -o out -h in/*.xml
[main] INFO de.kosit.validationtool.api.CheckConfiguration - Creating default scenario repository (alongside scenario definition)
[main] INFO de.kosit.validationtool.impl.ScenarioRepository - Loading scenarios from file:///D:/pk32_test/pk32/Ci/sv/scenarios.xml
[main] INFO de.kosit.validationtool.impl.ContentRepository - Load schema from source file:/D:/pk32_test/pk32/Ci/sv/lib/validationtool-1.0.1-standalone.jar!/xsd/scenarios.xsd
[main] INFO de.kosit.validationtool.impl.ScenarioRepository - Loaded scenarios for Prüftool-Konfiguration für XGewerbeanzeige by KoSIT from 2018-11-28. The following scenarios are available:

XGewerbeanzeige 1.2 DATML/RAW
XGewerbeanzeige 1.3 DATML/RAW
XGewerbeanzeige 2.0

[main] INFO de.kosit.validationtool.impl.ScenarioRepository - Loading scenario content from file:/D:/pk32_test/pk32/Ci/sv/
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/xgewerbeanzeige-1.2/00041740059999000001.xsl
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/default-report.xsl
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/xgewerbeanzeige-1.3/00041840059999000001.xsl
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/default-report.xsl
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/xgewerbeanzeige-2.0/spezifikation.xsl
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/default-report.xsl
[main] INFO de.kosit.validationtool.impl.ContentRepository - Loading XSLT script from  resources/default-report.xsl
[main] INFO de.kosit.validationtool.cmd.CommandLineApplication - Setup completed in 11343ms

[main] INFO de.kosit.validationtool.impl.DefaultCheck - Checking content of in\ele_20181127132744.xml
[main] INFO de.kosit.validationtool.cmd.ExtractHtmlContentAction - Writing report html 'ele_20181127132744-report' to D:\pk32_test\pk32\Ci\sv\out\ele_20181127132744-report.html
[main] INFO de.kosit.validationtool.cmd.SerializeReportAction - Serializing result to D:\pk32_test\pk32\Ci\sv\out\ele_20181127132744-report.xml
[main] INFO de.kosit.validationtool.impl.DefaultCheck - Finished check of in\ele_20181127132744.xml in 27172ms

[main] INFO de.kosit.validationtool.impl.DefaultCheck - Checking content of in\ele_20181127133238.xml
[main] INFO de.kosit.validationtool.cmd.ExtractHtmlContentAction - Writing report html 'ele_20181127133238-report' to D:\pk32_test\pk32\Ci\sv\out\ele_20181127133238-report.html
[main] INFO de.kosit.validationtool.cmd.SerializeReportAction - Serializing result to D:\pk32_test\pk32\Ci\sv\out\ele_20181127133238-report.xml
[main] INFO de.kosit.validationtool.impl.DefaultCheck - Finished check of in\ele_20181127133238.xml in 61406ms

[main] INFO de.kosit.validationtool.impl.DefaultCheck - Checking content of in\ele_20181127133656.xml
[main] INFO de.kosit.validationtool.cmd.ExtractHtmlContentAction - Writing report html 'ele_20181127133656-report' to D:\pk32_test\pk32\Ci\sv\out\ele_20181127133656-report.html
[main] INFO de.kosit.validationtool.cmd.SerializeReportAction - Serializing result to D:\pk32_test\pk32\Ci\sv\out\ele_20181127133656-report.xml
[main] INFO de.kosit.validationtool.impl.DefaultCheck - Finished check of in\ele_20181127133656.xml in 179329ms

[main] INFO de.kosit.validationtool.impl.DefaultCheck - Checking content of in\ele_20181127134111.xml
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
        at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
        at de.kosit.validationtool.impl.tasks.DocumentParseAction.parseDocument(DocumentParseAction.java:65)
        at de.kosit.validationtool.impl.tasks.DocumentParseAction.check(DocumentParseAction.java:83)
        at de.kosit.validationtool.impl.DefaultCheck.runCheckInternal(DefaultCheck.java:112)
        at de.kosit.validationtool.cmd.InternalCheck.lambda$checkInput$0(InternalCheck.java:61)
        at de.kosit.validationtool.cmd.InternalCheck$$Lambda$24/18230464.accept(Unknown Source)
        at java.util.ArrayList.forEach(Unknown Source)
        at de.kosit.validationtool.cmd.InternalCheck.checkInput(InternalCheck.java:59)
        at de.kosit.validationtool.cmd.CommandLineApplication.processActions(CommandLineApplication.java:155)
        at de.kosit.validationtool.cmd.CommandLineApplication.mainProgram(CommandLineApplication.java:105)
        at de.kosit.validationtool.cmd.CommandLineApplication.main(CommandLineApplication.java:85)

On macOS 10.15.7, Java version 1.8.0_261, in the US Pacific time zone (-0700):

Executing 'mvn test' from a clean clone of tag v1.4.0 results in the following error:

[ERROR] Failures: 
[ERROR]   ConfigurationBuilderTest.testDate:99 expected:<"19[70-01-0]1"> but was:<"19[69-12-3]1">

If I had to guess, I would imagine this has to do with the time zone in which the test is run.

Validator 1.1.x is vulnerable to XXE attacks since reading files with saxon is not properly secured

Wir versuchen derzeit den HTTP Daemon zum Laufen zu bringen und testen das anhand einer gültigen ubl.xml aus der Testsuite aus.
Wenn wir den Befehl:
java -jar validationtool-1.3.1-java8-standalone.jar -s scenarios.xml -h ubl.xml
ausführen, ist die Antwort auch "ACCEPTABLE", wie erwartet.

Wenn wir den Daemon starten mit:
java -jar validationtool-1.3.1-java8-standalone.jar -s scenarios.xml -D -P 8081
und dann
curl --location --request POST 'http://127.0.0.1:8081' --header 'Content-Type: application/xml' --data-binary './ubl.xml'
ausführen erhalten wir folgende Fehlermeldung im Log vom Daemon:

2020-09-25 11:47:24 [INFO] Server /127.0.0.1:8081 started
2020-09-25 11:47:35 [INFO] Checking content of supplied_instance_1
Error on line 1 column 1 of supplied_instance_1:
  SXXP0003: Error reported by XML parser: Content ist nicht zulässig in Prolog.
2020-09-25 11:47:35 [ERROR] No valid scenario configuration found for supplied_instance_1
2020-09-25 11:47:35 [INFO] Finished check of supplied_instance_1 in 168ms

Ich hätte erwartet, dass auch mit dem Daemon das Dokument als valide angesehen wird. Was machen wir falsch?

Following situation:
I use the Kosit Validator as library within another application, which is packaged as jar. The scenario and xsl files are included in the jar as resource files. I specified the URI to the scenario correctly so that the scenario file within the jar is used. When the Validator is build it tries to load the xsl files, which are specified in the scenario file. The constructor fails because the URI cannot be resolved
The error is file not found because line 117 in ContentRepository is not correctly working
return new StreamSource(this.repository.resolve(source).toASCIIString());

I do not know if this is the correct repository. Maybe it is related to itplr-kosit/validator.

Reproduction:
java -jar validationtool-1.3.1-standalone.jar -s validator-configuration/scenarios.xml -h validator-configuration/test/testsuite/01.13a-INVOICE_ubl.xml

Generates files:
01-report.01a-INVOICE_ubl => Suffix is missing
01.01a-INVOICE_ubl-report.html

Hallo zusammen,

ähnlich wie in Issue #45 verwende ich den Validator in einer andere Applikation. Jedoch basiert diese nicht auf Spring Boot, wie in Issue #45.

Dabei rufe ich die scenarios.xml wie folgt auf:

 // Load scenarios.xml from classpath
URL scenarios = this.getClass().getClassLoader().getResource("validator/scenarios.xml");
// Load the rest of the specific Validator configuration from classpath
 ConfigurationLoader config = Configuration.load(scenarios.toURI());
// Use the default validation procedure
 Check validator = new DefaultCheck(config.build());
 // Validate a single document
 Input document = InputFactory.read(Paths.get(inputXML));
 // Get Result including information about the whole validation
Result report = validator.checkInput(document);

Allerdings bekomme ich anschließend diese Fehlermeldung:

Caused by: org.xml.sax.SAXParseException: Externes Schemadokument "jar:file:/Testprogram/LIB/test.jar!/validator/resources/ubl/2.1/xsd/common/UBL-CommonAggregateComponents-2.1.xsd" konnte nicht gelesen werden, weil der Zugriff ("jar") nicht zulässig ist.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager$2.reportError(Unknown Source)
at com.ibm.xml.jaxp.util.ExternalResourceHelper$ProtocolValidator.validate(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown Source)
at de.kosit.validationtool.impl.ContentRepository.createSchema(ContentRepository.java:77)
... 29 common frames omitted

Es wäre sehr hilfreich ein Tool für den Gesamtprozess Validierung -> Konvertierung -> Visualisierung nutzen zu können.

Ist es möglich, die scenarios.xml neben dem XML-Tag "createReport" um XML-Tag "createXR" und "createHTML" zu erweitern?
Für das XML-Tag "createXR" ist an der Stelle schon festgestellt, welcher Ursprungstyp geliefert wurde und ob dieser validiert werden konnte.
Für das XML-Tag "createHTML" liegt dann schon das konvertierte XR-Dokument vor und kann verarbeitet werden.

Die Rückgabe könnte dann ebenfalls komplett mit einem Response erledigt werden.

Uns würde es sehr helfen, das Tool per Webservice anzusprechen und alle nötigen Informationen zur Weiterverarbeitung aufzubereiten.

I followed the instructions and got the following error
java -jar validationtool-1.0.1-standalone.jar -s scenarios.xml -h ubl.xml

Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at de.kosit.validationtool.impl.DefaultCheck.(DefaultCheck.java:73)
at de.kosit.validationtool.cmd.InternalCheck.(InternalCheck.java:48)
at de.kosit.validationtool.cmd.CommandLineApplication.processActions(CommandLineApplication.java:135)
at de.kosit.validationtool.cmd.CommandLineApplication.mainProgram(CommandLineApplication.java:105)
at de.kosit.validationtool.cmd.CommandLineApplication.main(CommandLineApplication.java:85)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)

My Java Version:
java version "14.0.1" 2020-04-14
Java(TM) SE Runtime Environment (build 14.0.1+7)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

Currently, validator has a strict XML security policy and only allows loading XML Schema from local file resources.

Some users want a less strict security policy in their runtime context. Therefore, I consider this a useful feature.

final Conifuguration config = Configuration.load(URI.create("scenarios.xml")).resolvingMode(ResolvingMode.STRICT_LOCAL).build();

Führt zu folgender Exception:

2020-11-16 18:01:29,091 [main] INFO  de.kosit.validationtool.config.ConfigurationLoader - Using resolving strategy STRICT_LOCAL

java.lang.SecurityException: class "net.sf.saxon.lib.Feature"'s signer information does not match signer information of other classes in the same package

	at java.lang.ClassLoader.checkCerts(ClassLoader.java:898)
	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:668)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:761)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at de.kosit.validationtool.impl.xml.StrictRelativeResolvingStrategy.createProcessor(StrictRelativeResolvingStrategy.java:106)
	at de.kosit.validationtool.impl.xml.BaseResolvingStrategy.getProcessor(BaseResolvingStrategy.java:52)
	at de.kosit.validationtool.config.ConfigurationLoader.build(ConfigurationLoader.java:136)

Konfigurationsdateien liegen local vor. Verstehe nicht, warum diese Exception geworfen wird.

see also: #43

After upgrade to validator 1.2.0 and configuration 1.2.2_2019-12-30; I ran all test-documents against the validator again:

For this example

/instances/01.15a-INVOICE_ubl.xml

I get an "Reject" State, but the Fehlerreport has only the expected "Warning" and the "positive" Information:

"Bewertung: Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten."

The same with

02.01a-INVOICE_ubl.xml

Do I Miss anything?

I'm new to this repo, so please bear with me if I'm getting something wrong.

Currently, the copyright and license header looks like this:

<!--
  ~ Licensed to the Koordinierungsstelle für IT-Standards (KoSIT) under
  ~ one or more contributor license agreements. See the NOTICE file
  ~ distributed with this work for additional information
  ~ regarding copyright ownership.  KoSIT licenses this file
  ~ to you under the Apache License, Version 2.0 (the
  ~ "License"); you may not use this file except in compliance
  ~ with the License. You may obtain a copy of the License at
  ~
  ~ http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~ Unless required by applicable law or agreed to in writing,
  ~ software distributed under the License is distributed on an
  ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  ~ KIND, either express or implied. See the License for the
  ~ specific language governing permissions and limitations
  ~ under the License.
  -->

I think this is misleading, if not wrong:

First, there is no copyright claim at all. I suppose the "Koordinierungsstelle für IT-Standards (KoSIT)" is the copyright owner, right? Then the first line should actually have a copyright claim like this:

Copyright © 2019 - 2020 by Koordinierungsstelle für IT-Standards (KoSIT)

where 2019 is the year of inception and 2020 the year of the last edit. With no copyright claim at all however, according to US legislation (and maybe in other countries, too), this would not be copyrighted material. I'm no lawyer, though, so I maybe wrong.

Next, I think the meaning of the first sentence is that KoSIT is the actual copyright owner and licenses this material under the terms and conditions of the ASL 2, right? Then the second word, which is "to", should be replaced with "by". In the current text however, KoSIT is licensing their own work to themselves. :-)

Last, but not least, you could swap the license boiler plate with the recommended form, which you can find at the very end of this page: http://www.apache.org/licenses/LICENSE-2.0