Re: Saxon and FileURLConnection

> > 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