Subject: Re: [xsl] Saxon and FileURLConnection From: David Tolpin <dvd@xxxxxxxxxxxxxx> Date: Mon, 8 Dec 2003 14:35:23 +0400 (AMT) |
> > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Saxon and XT both exhibit, Michael Kay | Thread | RE: [xsl] Saxon and FileURLConnecti, Michael Kay |
RE: [xsl] Saxon and XT both exhibit, Michael Kay | Date | Re: [xsl] Fixed Line Length Output, Mukul Gandhi |
Month |