Saxon

I think I can hazard a guess: the Singulink.Numerics.BigDecimal.Parse() method is expecting a decimal number in a localised format depending on the current culture set on your machine, whereas we're expecting it to handle culture-neutral (or English) format.

I'll explore that to see if I can confirm it.

Thanks for a very fast hint!

Yes, setting Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB"); solved most of the problems.

Only two problems are left:

XPathWithStaticError

Saxon.Api.SaxonApiException Cannot find a 0-argument function named Q{http://www.w3.org/2005/xpath-functions}unknown() at Saxon.Hej.s9api.XPathCompiler.internalCompile(String source) at Saxon.Hej.s9api.XPathCompiler.compile(String source) at Saxon.Api.XPathCompiler.Compile(String source) at SaxonEE.XPathWithStaticError.run(Uri samplesDir) in C:\Git\SaxonCS\SaxonEE\Examples.cs:line 424 at Tests.UnitTests.ExampleTest(Int32 index) in C:\Git\SaxonCS\Tests\UnitTests.cs:line 134

XPathWithDynamicError

Saxon.Api.SaxonApiException Cannot compare xs:int to xs:string at Saxon.Hej.s9api.XPathSelector.evaluateSingle() at Saxon.Api.XPathSelector.EvaluateSingle() at SaxonEE.XPathWithDynamicError.run(Uri samplesDir) in C:\Git\SaxonCS\SaxonEE\Examples.cs:line 457 at Tests.UnitTests.ExampleTest(Int32 index) in C:\Git\SaxonCS\Tests\UnitTests.cs:line 134

I added a -locale option to the test driver, and tried running with -locale:de-DE. The effect of the option is to set Thread.CurrentThread.CurrentCulture. There was a minor glitch in DotNetPlatform.getDefaultCountry() (used by format-number()) but with this fixed, everything ran smoothly.

The same is true if I set it in Examples.cs.

I was hoping this would enable me to reproduce the bug, but it seems it's not so easy.

Although I haven't found a way to reproduce it and therefore to test any fix, it's reasonably obvious what the fix should be. The transpiler needs to convert java new BigDecimal(%string%) to Singulink.Numerics.BigDecimal.Parse(%string%, NumberStyles.Number, CultureInfo.InvariantCulture)

The rule for this is in transpiler/constructors.xsl line 76.

I see a culture dependency on serializing a decimal number, 'C:\Program Files\Saxonica\SaxonCS-11.0\SaxonCS.exe' query -qs:'1.3' gives <?xml version="1.0" encoding="UTF-8"?>1,3 for me.

Setting Set-Culture en-US in Powershell and opening a new Powershell window makes SaxonCS return 1.3. The previous culture info (Get-Culture) was de-DE.

Thanks Martin. I'll give it a try on Windows in due course.

Saxon's doing decimal-to-string conversion using a straightforward call on Singulink.Numerics.BigDecimal.ToString(). Despite the fact that the documentation for this method says it uses exponential notation, this doesn't appear to be the case. The documentation doesn't mention anything about culture, but stepping through the code it's clear it uses the culture-specific decimal point, so I'll have to change it to use the static method BigDecimal.ToString(value, "G", CultureInfo.Invariant). The code is in an annotation on the Java method BigDecimalValue.decimalToString() rather than in the transpiler.