In both cases, the specification requires a URI, not a windows filename. But if you write your own URIResolver / OutputURIResolver then you're in full control.

The standard output URI resolver recognizes the "file" protocol specially and uses normal file system IO; for any other URI scheme it tries to open a writable connection using the Java URL library, but this will usually fail (I believe that Java can be configured so that it might work with some URI schemes like webdav and ftp, but I've never managed to make it work myself). Certainly using a URI scheme of "c" is pretty well guaranteed to fail.

For the doc() function, Saxon tries to make the supplied URI absolute, and then passes it to the XML parser. So if you supply something like c:/a/b/c that conforms to the syntax of an absolute URI, and if the XML parser accepts it, then it will work. But in my view, an XML parser that accepts such a URI is being liberal in its interpretation of the specs.

Michael Kay

On 7 May 2014, at 09:10, Hans-Juergen Rennau <> wrote:

Hello Saxon team,

it seems to me that the Saxon implementation of xsl:result-document does not accept file paths starting with a windows drive, like


A preceding "file:/" is required, which is not the case after removing the drive specification (/a/b/c).

The fn:doc function, on the other hand, accepts a path starting with a drive.

Maybe this difference is intended - maybe not. At least it is a little confusing.

Kind regards,
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
saxon-help mailing list archived at