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

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

Recent Java releases include methods to convert a filename to a URL.
Saxon 6.5.x was written to avoid any dependency on JDK 1.2 (remember
that there has been no new development on 6.5.x for two years), and so
it instead uses the createURL algorithm (which performs the "reslashing"
described by David Tolpin). This method comes originally from a
Microsoft source, and is commented as "a bunch of weird code that is
required to make a valid URL on the Windows platform, due to
inconsistencies in what getAbsolutePath returns." Not very satisfactory,
but a lot of problems (of the form "it doesn't work on platform X") went
away when I put it in. Fortunately, though, you don't have to use this
code: it is NOT used when resolving relative URIs, it is used only when
converting a file name to a URI, which is something that's outside the
scope of any specs, and which you can avoid doing if you only ever
specify URIs rather than filenames.

Michael Kay


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