Project

Profile

Help

Support #4687

[F-INV133] when document is OK

Added by Jesper Arberg about 1 year ago. Updated about 1 year ago.

Status:
Won't fix
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2020-08-17
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:

Description

From Visual Studio in a C# project I am using NUGET Saxon-HE version 9.9.1.7 (the newest). I have an OIOUBL invoice that fails in the schematron validation, even that is is ok when I use the the official online validator for OIOUBL: http://www.oioubl.net/validator/ (and that one uses the same xslt files as I do) I fails with [F-INV133] It seem that the problem has something to do with rounding. I am using the newest official schematron fil (attached) that gives the faiture. When the use the Microsoft schematron NUGET it passes, but the MS one only supports xslt version 1.

History

#1 Updated by Michael Kay about 1 year ago

Adding some xsl:message tracing, it appears the test fails with

LHS = -.00 
RHS = .00

That is, the expression on the left, format-number(sum(cbc:PayableAmount) *-1,'##.00') is returning "-.00".

This raises two questions, (a) should zero times -1 evaluate to negative zero, and (b) should format-number() applied to negative zero include a leading minus sign?

Note that the stylesheet specifies version="1.0" so we have to answer this questions for the case where 1.0 backwards compatibility applies.

Although I don't have the IEEE floating point spec to hand, I'm pretty sure the answer to (a) is yes: the multiplication yields negative zero. As for (b), reading the rules for format-number() in the Functions&Operators 3.1 spec clearly says yes: if the value is negative zero, it is formatted with a leading minus sign. There's no special rule here for backwards compatibility mode, but it's interesting to see whether the spec here has changed since XSLT 1.0. Unfortunately the spec for format-number() in XSLT 1.0 refers normatively to the spec for the DecimalFormat class in Java version 1.1.8, which is no longer obtainable; but it was grossly underspecified; indeed, the spec in more modern Java versions is still rather vague, though I read at saying that a "-" sign is included by default.

I've tried this under a number of XSLT processors invoked from Oxygen: specifically looking at the result of format-number(0.0 * -1, '##.00'). The results I get are:

Saxon 9.8:       -.00
Saxon 6.5.5:    -.00
Xalan:               -.00
xsltproc:           .00

Without being able to find the Java 1.1.8 specification, I think the XSLT 3.0 specification clearly requires -.00, and the 1.0 specification is either the same, or is ambiguous.

I would suggest that you replace (XXX * -1) by (0.0 - XXX) as the preferred way to make a number negative. This delivers positive zero rather than negative zero as the result, and the formatting is then the same for all processors.

#2 Updated by Michael Kay about 1 year ago

  • Tracker changed from Bug to Support
  • Status changed from New to Won't fix

Reclassifying. I believe Saxon is working correctly according to the W3C specification.

Please register to edit this issue

Also available in: Atom PDF