This sounds like the right thing to do. By default saxon
command line arguments are specified as being file names
rather than URIs (so should use \ (although / also works, as
is normally the case with command line tools on windows) but
then that file name must be converted to a uri which means
more or less changing \ to / and sticking file:// at the front.
But this code in Saxon is not invoked when executing the document()
function!
Michael,
you are right, createURL is not used for xsl:import and xsl:include
(that is, where backslashes are handled differently under Unix and Windows). I
thought the code was the same for the command line and import arguments and
was wrong.
I am sorry.
The cause of the problem (xsl:import href="data2\ss2.xsl" -- what's the base
URL for ss2.xsl?) is in sun.net.www.protocol.file.Handler, which is the
implementation
of java.net.URLStreamHandler for file: protocol. It contains (jdk 1.3.1,
previous releases
mentioned are before 1.2.2, I think):
: protected void parseURL(URL u, String spec, int start, int limit) {
: /*
: * Ugly backwards compatibility. Flip any file separator
: * characters to be forward slashes. This is a nop on Unix
: * and "fixes" win32 file paths. According to RFC 2396,
: * only forward slashes may be used to represent hierarchy
: * separation in a URL but previous releases unfortunately
: * performed this "fixup" behavior in the file URL parsing code
: * rather than forcing this to be fixed in the caller of the URL
: * class where it belongs. Since backslash is an "unwise"
: * character that would normally be encoded if literally intended
: * as a non-seperator character the damage of veering away from the
: * specification is presumably limited.
: */
: super.parseURL(u, spec.replace(File.separatorChar, '/'), start, limit);
: }
that is, changes every '\' to '/' on win32 platforms. This is done
intentionally,
causes bugs in stylesheets developed on Windows and run either on Unix or
remotely,
and easy to fix by installing a custom implementation of 'file' protocol
handler,
at least, for most java current java installations (>=1.3.1).
My impression is the damage of veering away from the specificitaion is serious
in the
case of XSLT and handling of xsl:import, xsl:include, and document(). A
stylesheet
that handles data.xml in each level of a deep hierarchy on a local disk, but
only
processes the top-level data.xml when run on a Unix server or remotely via http
is a potential danger.
Does SAXON 7 exhibit the same behavior?
David
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list