Re: Saxon and XT both exhibit unexpected document() be

> Both Saxon and xt have a version that is prepackaged to use the
> Microsoft JVM, and (probably) both are using the java.net.URL class to
> resolve relative URIs. So if the answer is wrong, you can probably blame
> the Microsoft JVM. 

Yes, this is a bug in Microsoft JVM. But the result described by Ken Holman is
oposite to one that can be observed if RFC 2396 were not followed. It looks
like it is a bug in Microsoft's libraries for handling file paths, not URLs.

> As others have pointed out, this comes down to a
> question of whether the JVM is handling "\" in accordance with RFC 2396.

SAXON 6.5.3 and XT both use java.net.URL to resolve paths. Recent versions
of Sun JVM parse URLs in strict accordance to RFC 2396. However, a different
usecase shows that SAXON 6.5.3 (I am sorry I didn't test XT when I had access
to a Windows machine and I cannot say for sure from the source code) displays
a different but still non-conformant behaviour.

It happens not because the library deviates from RFC 2396 (Sun JDK 1.3.1 runtime
follows it strictly) but because SAXON sets systemId of the included stylesheet
by calling createURL on the file's name, and then setSystemId on the created file.

createURL contains explicit code to re-slash the path (ExtendedInputSource.java).

Thus, it is not related to the extent Java Runtime follows RFC 2396, but is caused
by the way SAXON computes systemId of a file, namely, by forcing reslashing the path
to the UNIX way, which leads to non-conformant behaviour.

I would prefer the url's not to be reslashed on Windows platforms, as it hides
errors and complicates debugging; however, as David Carlisle has mentioned, the
client-side URL transformation is a tricky part.

David Tolpin
http://davidashen.net/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list