Closed jorgeimar closed 1 year ago
That is indeed weird. When using the "Pure" implementation, it works, when switching to the XSLT-based version it fails. I'm trying to find out what's going wrong.
Hello Philip,
Thanks for your help, i didnt notice about the pure implementation, ill check that. I’ll wait for your comments about the xslt based versión.
Regards!!!
Enviado desde mi iPhone
El 25 sep 2019, a la(s) 5:04, Philip Helger notifications@github.com escribió:
That is indeed weird. When using the "Pure" implementation, it works, when switching to the XSLT-based version it fails. I'm trying to find out what's going wrong.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Hello Philip, have you found why the xslt-based version doesn't work?.
Thanks in advace
No unfortunately not, I am stuck - something with the namespaces but I don't know what :( Its weird..
Hi, I tried this out with yesterday's 5.2.1 anttask snapshot.
Using SchematronResourcePure
, I get no failed-assertion
s and no successful-report
s.
Using SchematronResourceSCH
instead, I get a successful-report
, whose flag is however ERROR
, in light of the log message:
[main] WARN com.helger.schematron.svrl.DefaultSVRLErrorLevelDeterminator - Cannot convert the SVRL flag 'CFDI33195' to an error level. Using default error level instead!
So I'm a bit confused... it seems to me the XSLT version does produce the expected output, albeit with a modified flag
value. But I guess the point is that both "pure" and XSLT-based should tally with one another :)
So I think I tracked down the problem. The XSLT based version is handling the LET differently than the pure version:
<sch:let name="impuesto" value="@Impuesto"/>
<sch:let name="tasaOCuota" value="@TasaOCuota"/>
In XSLT the "@Impuesto" is actually resolved to the value of the XML attribute "Impuesto", in the pure implementation it uses "@Impuesto" as a String --> the time of evaluation of "@Impuesto" is different which creates the difference.
This is a bug in the pure implementation. For my own reference:
The ISO 2016 spec states on that in general:
The variable is substituted into assertion tests and other expressions in the same rule before the test or expression is evaluated. The query language binding specifies which lexical conventions are used to detect references to variables.
Default query language binding states:
The let value is interpreted according to Production 14 of XPath, as returning a string value.
and
A Schematron let expression is treated as an XSLT1 variable. The XSLT1 $ delimiter signifies the use of a variables in an context expression, assertion test, name query, value-of query or let expression. The character not followed by the name of an in-scope variable shall be treated as a literal character.
Query language binding for XSLT 2 states:
The let value is interpreted according to Production 1 of XPath2.
and
A Schematron let expression is treated as an XSLT2 variable. The XSLT2 $ delimiter signifies the use of a variables in an context expression, assertion test, name query, value-of query or let expression. The character not followed by the name of an in-scope variable shall be treated as a literal character.
Query language binding for XPath 2 states:
The let element should not be used.
Query language binding for EXSLT states:
The let value is interpreted according to Production 14 of XPath, as returning a string value.
and
A Schematron let expression is treated as an XSLT1 variable. The XSLT1 $ delimiter signifies the use of a variables in an context expression, assertion test, name query, value-of query or let expression. The character not followed by the name of an in-scope variable shall be treated as a literal character.
Query language binding for STX states:
The let value is interpreted according to Production 1 of STX,[3] as returning a string value.
and
A Schematron let expression is treated as an STX[3] variable. The STX[3] $ delimiter signifies the use of a variables in an context expression, assertion test, name query, value-of query or let expression. The character not followed by the name of an in-scope variable shall be treated as a literal character.
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.
Hi all,
I've been struggling with pure Schematron, XPath2 and variables. Today, in the logs, I noticed that variables are not properly substituted in the XPath filter predicates of my rule tests.
Is there any technical barrier that makes this issue unfixable?
I'm new to Schematron but this issue feels like a very serious limitation of Pure Schematron. I'm using ph-schematron 7.0.1.
Yes, that is a very severe limitation to pure-schematron - unfortunately. Please prefer the ISO Schematron solution, unless you are sure, you don't need that feature :(
The evaluation of XPath in Schematron variables will be a performance penalty - maybe this can be done with an opt-in/opt-out mechanism
Closing this in favour of the newer #143 - tackle it there.
Part of the v8.0.0 release - finally
Hello, im using ph-schematron to validate data in an xml file but i found that the following rule is not being applied:
And im using the following xml:
When i use ph-schematron (ver 5.2.0) i got no errors but i expect to get the report flag CFDI33195. Using camel-schematron i got the flag i want. I really want to use PH-Schematron, could you help me?.
Thanks in advance.