Saxon

Project , XSLT and invoice provided via email. (sieben.devreese@advalvas-group.com)

I haven't been able to reproduce this yet, but I think you could be seeing a problem with the document-uri() function (see bug #5615, etc). We had to make changes to the document-uri() function because the implementation wasn't conformant with the W3C specs - the requirement that the returned URI is unique and always acceptable to the doc() function meant that we had to be much more restrictive in deciding which documents should have a document-uri(). See what happens if you use base-uri() instead.

Or, check what value document-uri() is actually returning. If it's a zero-length string, this could well lead to problems when you try to use the URI later.

The transformation works (apparently correctly) when run from the command line, and I've also run it successfully using the API, though I had to change the filenames to match my Mac filestore layout.

My next step would be to run it on a Windows machine; unfortunately I'm away from the office so I won't be able to do that until the middle of next week.

Are you sure the failure is coming from Saxon, and not simply from your call on "new Uri(...)" supplying a Windows filename? (Try making the same call on new Uri() in a separate statement, where Saxon is not involved).

Can you check the xslt handling in .net6 with SaxonCS installed?

Could you report the results of my suggested diagnostics, please?

I am not able to see the error the original poster got, nor the file used, but code like

var uri = new Uri("C:/Users/marti/OneDrive/Documents/EN16931-UBL-validation.xslt"); 
Console.WriteLine(uri.AbsoluteUri);

Processor processor = new();

var xslt30Transformer = processor.NewXsltCompiler().Compile(uri).Load30();

(with the file EN16931-UBL-validation.xslt downloaded from the public Github repository of that standard (https://github.com/ConnectingEurope/eInvoicing-EN16931)) runs fine for me on Windows 11 with SaxonCS 11.4.1 in a .NET 6 console application.

The uri.AbsoluteUri is output as file:///C:/Users/marti/OneDrive/Documents/EN16931-UBL-validation.xslt. Neither the Compile nor the Load call gives any error and I can run the XSLT Schematron validation fine with a sample taken also from that repository (e.g.

var input = processor.NewDocumentBuilder().Build(new Uri("https://github.com/ConnectingEurope/eInvoicing-EN16931/raw/master/ubl/examples/ubl-tc434-example1.xml"));

xslt30Transformer.GlobalContextItem = input;

xslt30Transformer.ApplyTemplates(input, processor.NewSerializer(Console.Out));

HTH. Otherwise just ignore me, as I said, the error the original poster encountered is not visible to me.

I have tried the code Martin provided. This writes the Uri correctly to output, it does not seem like that is the issue. Is it possible I have issues because I'm using Windows 10?

The Java-to-C# transpiler is translating java.lang.Double.parseDouble(n) to System.Double.Parse(n), when it should be System.Double.Parse(n, CultureInfo.InvariantCulture) (note, we've already checked the format is correct, this call is only to do the conversion).

In fact it would probably make sense for the transpiler to generate a call on a helper method so that we can get the exception handling right. The code in StringToNumber does the right thing and should be copied.

Although the fix is straightforward, I'm having some trouble replicating the error, which means I haven't really tested it.

The test driver has an option which I can set to -locale:nl-BE and this doesn't trigger the failure, even though it is correctly setting the CurrentCulture: the call on Double.Parse("0.2") correctly parses the value (as 0.2000000000000...0001). But if I call Double.Parse with the culture explicitly set to "nl-BE", it parses "0.2" as "2" (presumably treating the "." as a thousands separator).

The problem is that the default behaviour of Double.Parse seems to depend on a great number of configuration settings, so it's probably going to be hard to reproduce the exact settings that trigger the failure. So I think I'll content myself with assuming that a specific setting of CultureInfo.InvariantCulture will do the job.