Saxon

It's really difficult to get this right in a cross-platform way. The whole file: scheme is un(der)specified at best.

Could you please clarify:

(a) Under what conditions does the URI resolver get called with a "file:/" URI?

(b) What exactly is not allowed under Windows, and how does it fail?

(Note, the URI manipulation done by DocumentKey.normalizeURI() should only be used to compare whether two URIs are equivalent; it's not intended that it should produce a URI that can be dereferenced, and I don't immediately see how the result can find its way into a call of the URIResolver. But I'm open to persuasion if you can tell us exactly what you are doing and exactly how it fails.)

Like almost everything else concerned with the file URI scheme, the Wikipedia article is thoroughly confused, and rarely makes it clear which specification it is referring to. For example the sentence "These are called "legacy" file URLs as opposed to "healthy" file URLs." links only to an anonymous personal blog entry dating back to 1997, and which is now available only on the Wayback machine: it's not authoritative information in any way.

Moreover, I don't quite see how you justify your claim "According to Wikipedia "file://" and "file:///" are allowed under Windows, "file:/" is only allowed under UNIX." from the Wikipedia article (let alone from the definitive RFCs). In practice it's not what "Windows" allows that matters, it's what specific software running under Windows allows, for example the Java or .NET class libraries.

You don't make it clear what API code you are using to run the transformation. This is critical.

Thanks, but what are the inputs being supplied to the XsltTransformer and XsltCompiler -- specifically, how do you specify the stylesheet and source document locations?

I did some tests under Windows with Java. I found that in Java both "file:/" and "file:///" are allowed and "file:/" is preferred:

URL url = new URL("file:/C:/FOLDER/File.txt"); url.toString(); << file:/C:/FOLDER/Filter.txt

URL url = new URL("file:///C:/FOLDER/File.txt"); url.toString(); << file:/C:/FOLDER/Filter.txt

I don't think it is a Saxon problem, or even a Java problem. I will have to accept that Java prefers "file:/" over "file:///".

Yes. There's a fair bit of effort to work around these problems in XML Resolver. See, for example, the collection of ad hoc mitigations in

https://github.com/xmlresolver/xmlresolver/blob/main/src/main/java/org/xmlresolver/utils/URIUtils.java

But Michael is right, in order to understand the problem, we need to see the precise APIs and inputs involved.

The XSLT input is a SAXSource (XMLBlueprintSAXSource extends SAXSource):

// https://www.saxonica.com/documentation12/#!javadoc/net.sf.saxon.s9api/XsltCompiler 
XsltCompiler compiler = processor.newXsltCompiler();
compiler.setCompileWithTracing(traceList != null);
compiler.setErrorReporter(new XMLBlueprintS9APIErrorReporterToListener(new XMLBlueprintS9APIErrorListener(errorWriter), xsltInputData.getURL())); // errorWriter!
compiler.setResourceResolver(new ResourceResolverWrappingURIResolver(resolver)); // resolver(<import>, <include>)!

// https://www.saxonica.com/documentation12/#!javadoc/net.sf.saxon.s9api/XsltExecutable
**XsltExecutable executable = compiler.compile(new XMLBlueprintSAXSource(xsltInputData, resolver, errorWriter)); // resolver(XInclude)! errorWriter!**

// https://www.saxonica.com/documentation12/#!javadoc/net.sf.saxon.s9api/Xslt30Transformer
Xslt30Transformer transformer = executable.load30();
transformer.setBaseOutputURI(xsltInputData.getURL());

The XML input is an XdmItem (called xomInputTree):

**transformer.setGlobalContextItem(xomInputTree);**
transformer.applyTemplates(xomInputTree, serializer);

What is the resolver in this line?

compiler.setResourceResolver(new ResourceResolverWrappingURIResolver(resolver)); // resolver(<import>, <include>)!

That's my own resolver

public class XMLBlueprintResolver implements EntityResolver2, LSResourceResolver, URIResolver {

	// URIResolver
	// https://docs.oracle.com/en/java/javase/19/docs/api/java.xml/javax/xml/transform/Source.html
	@Override
	public Source resolve(String href, String base) throws TransformerException{
		href = XMLBlueprintURLHelper.adjustURL(href); // !!!
		base = XMLBlueprintURLHelper.adjustURL(base); // !!!

XMLBlueprintURLHelper.adjustURL is where I have to convert "file:/" to "file:///".

Gerben, do you want to keep this issue open? I think if we're going to make progress with it then we need a concrete repro - something we can run on our own Windows machine that clearly demonstrates the problem.