Subject: RE: [xsl] Windows Batchfile calling Saxon - Confusion of / and \|
From: "Houghton,Andrew" <houghtoa@xxxxxxxx>
Date: Thu, 11 Oct 2007 10:47:46 -0400
> From: Paul Spencer [mailto:xml-dev-list@xxxxxxxxxxxxxx] > Sent: 11 October, 2007 09:49 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: RE: [xsl] Windows Batchfile calling Saxon - > Confusion of / and \ > > Michael Kay wrote: > > > There are unfortunately many products that accept Windows > filenames in > > contexts where the standards mandate a URI. I have been resisting > > doing this, because I think standards conformance should outweigh > > minor convenience. However, I've been dithering a little on > this one > > recently, because once everyone breaks a standard in the same way, > > they establish a new de facto standard. > > Keep resisting Michael! One of the annoying things about XML > Spy is that it creates filenames with backslashes where there > should be a URI. Then, of course, it accepts them. So anyone > who doesn't test with another processor is likely to release > stuff that doesn't work. Some of us rely on tools that do it > properly for our testing. The original problem that raised this issue has to do with how the Windows command processor works, which prefers to generate file names with backward slashes. As Michael indicated, the Windows API that is used by every application will generally accept file names with either forward or backward slashes. So the person who brought up the issue could have just used forward slashes, right? It's not that simple when you type commands into the Windows command processor or create a batch command file and run it. Lets take a simple example. Here is a Windows command that when run from the command prompt will list the fully qualified names of all the files in a directory: for %f in (C:/foo/*) do @echo %~ff Notice that the directory specification is given with forward slashes, but if you put some file in the foo directory named file1.txt and file2.txt, then you will get the following output: C:\foo\file1.txt C:\foo\file2.txt Windows did accept the original directory specification with forward slashes, but because the file specification was manipulated by the command processor it reverted back to backward slashes. This might have been part of the reason why the person raised the issue, by not being aware of what the Windows command processor was doing and the construction rules for the HTTP file: scheme. As Michael previously indicated, if you try to open the file C:\foo\bar.txt or C:/foo/bar.txt the correct thing will happen. In addition, you can also send the Windows API the corresponding HTTP file: scheme versions, file:///C:/foo/bar.txt or file:///C:\foo\bar.txt. The Windows API is slightly schizophrenic, in that you can even mix forward and backward slashes for the file specification. So C:\foo/bar.txt or C:/foo\bar.txt will work, as well as, file:///C:\foo/bar.txt or file:///C:/foo\bar.txt. RFC 1738, section 3.10 indicates that the file URI's path is separated by forward slashes. So being a Windows user of Saxon, I personally don't have any issues with Saxon strictly conforming to the RFC. However, it should be possible to detect that Saxon is running under Windows and relax the conformance to local OS practice and user's expectations. If it is decided that Saxon should not change it behavior under Windows, then there is a simple work around that I mentioned in my prior post and perhaps the issue and work around could be mentioned in the Saxon documentation for Windows users. Andy.