Saxon

Even when 9.5 is the bugged one; 9.6 seems to handle it incorrectly aswell. The Uri instance does show an escaped AbsoluteUri value of file:///c:/path%20with%20space/nonexistant.xsl (or c:/path%20with%20space/nonexistant.xsl for @AbsolutePath@).

But ok, I just checked and tried @new Uri(@@@"c:\path%20with%20space\nonexistant.xsl")@, which technically works (but shows incorrect values for @AbsoluteUri@: @file:///c:/path%2520with%2520space/nonexistant.xsl@).

As far as I could see, you seem to use Uri.ToString() inside @XsltCompiler.Compile@. In this case, it apparently returns the unescaped version as was passed to the ctor (from @Uri.OriginalString@).

But then again, this also happened in 9.5; so I'm not exactly sure what changed to cause this.

According to MSDN - Uri.ToString":https://msdn.microsoft.com/en-us/library/system.uri.tostring.aspx this returns the canonical representation (which includes spaces), not an encoded one. Also, "MSDN - Uri Class lists this in the remarks section: ??You can transform the contents of the Uri class from an escape encoded URI reference to a readable URI reference by using the ToString method.??

It might work to call MSDN - Uri.EscapeUriString on the result of uri.ToString@. I'd guess this change in @XsltCompiler.Compile(XmlReader) (@Xslt.cs@ line 537) could fix this:

But since I cannot manage to compile Saxon-HE from source, I can't really try this out...

Still, it's a bit odd that it suddenly stopped working after going from 9.5 to 9.6 - so something in there somewhere must have changed (IKVM changed for example, but I do hope that they didn't change behavior breaking everything).

I just tried this out, the code also fails when I pass a XmlReader that reads a file containing spaces in the path; aswell as when using the Uri Overload of @XsltCompiler.Compile@.

As far as I could see, the .NET Uri class may accept non-wellformed Uris and just make them; which is what seems to happen in my case. IsWellFormedOriginalString returns false for a Path that contains spaces that aren't escaped.

However, even if I pass a correctly escaped one (both IsWellFormedOriginalString and the static IsWellFormedUriString return true@), the result is still the same - since @Uri.ToString returns a readable instance, not a well-formed one.

Technically, .NET and Java do not seem to have differences on what a valid Uri is or not; but rather on how to deal with Uris that are not actually valid (.NET tries to make them valid by escaping some parts, Java throws if things do not validate).

So either way, I'm somewhat convinced that the line in XsltCompiler.Compile that takes BaseUri.ToString has to change as it looks like incorrect use of the API to me...but as you said, this might be a bigger task if it happens all over the place and now surfaces here.

I'm currently trying out a workaround to do exactly that from my code by deriving from Uri and overriding the ToString method - but longer term this does not seem to be like a useful fix for this either.

In investigating bug 2345, I found that what's changed between 9.5 and 9.6 is probably that the code for evaluating use-when expressions is now more rigorous in the way it computes the base URI for these expressions; as a result, the software is less tolerant of invalid URIs than it used to be.

Gave 9.6.0.7 a shot, no change so far. But I figured I might share my current workaround here (which I thought I already did earlier):

public sealed class SaxonUri : Uri
{
    public SaxonUri(Uri wrappedUri)
        : base(GetUriString(wrappedUri), GetUriKind(wrappedUri))
    {
    }
    private static string GetUriString(Uri wrappedUri)
    {
        if (wrappedUri == null)
            throw new ArgumentNullException("wrappedUri", "wrappedUri is null.");
        if (wrappedUri.IsAbsoluteUri)
            return wrappedUri.AbsoluteUri;
        return wrappedUri.OriginalString;
    }
    private static UriKind GetUriKind(Uri wrappedUri)
    {
        if (wrappedUri == null)
            throw new ArgumentNullException("wrappedUri", "wrappedUri is null.");
        if (wrappedUri.IsAbsoluteUri)
            return UriKind.Absolute;
        return UriKind.Relative;
    }
    public override string ToString()
    {
        if (IsWellFormedOriginalString())
            return OriginalString;
        else if (IsAbsoluteUri)
            return AbsoluteUri;
        return base.ToString();
    }
}

Simply wrap the URI being passed to compiler.BaseUri in that to get the modified ToString() behavior.

In case the originally passed URI string was well-formed already, we simply return that one as result from ToString()@; otherwise we try falling back to the absolute URI this particular URI-Instance produces. Absolute fallback is the same behavior as before; returning @base.ToString() which may trigger this issue again.

We had no failing reports with this so far, but YMMV.

I'll take another look. We're gradually making progress on this front: the W3C specs are gradually becoming more precise and we are getting more test cases. (But in the interests of precision, let's be clear: if it contains a space then it is not a URI. The fashionable term for things that aren't URIs but which many interfaces accept in lieu of a URI is a LEIRI - legacy internationalized resource identifier).

Michael Kay wrote:

(But in the interests of precision, let's be clear: if it contains a space then it is not a URI. The fashionable term for things that aren't URIs but which many interfaces accept in lieu of a URI is a LEIRI - legacy internationalized resource identifier).

Agreed, but I believe thats a point where .NET and Java handle things differently. If I pass in "path with spaces" to the .NET Uri ctor, the Uri class makes it "path%20with%20spaces" - which I do think makes it a valid URI. Doing so is most likely for convinience reasons, other than anything else.

Java, as far as I could see, requires me to do this myself before creating an @URI@-Instance. But then again, I haven't really done any Java code in the past 10 years, so things might be different now.

Plus, the aforementioned distinction in .NET between "something readable" (returned by @ToString()@) vs. "something valid" (returned by the various properties, depending on whether the original string was valid, the Uri is absolute/relative, and possibly other factors) which still breaks this, even when I explicitly pass in something I'd consider a valid URI (and not an IRI, LEIRI, IDN or whatever else).

Thanks for the follow-up, Mike! We're still waiting for the .NET release of 9.7 to be available so we can try this out.