RE: Windows Batchfile calling Saxon - Confusion of / a

> From: Paul Spencer [mailto:xml-dev-list@xxxxxxxxxxxxxx]
> Sent: 11 October, 2007 09:49
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  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.