So the person
who brought up the issue could have just used forward slashes,
right?
No. That would be me. And the reason I couldn't is pretty much
as indicated in the later part of Andrew's posting (below).
When I was generating full paths in my batch file I was generating
them using '/' as Saxon was only happy with those (for multiple
documents using document()).
When I finished doing the initial 'experimental' phase of my task
I needed to change the batch file so it no longer had the original
full path hard-coded in it and could be run from anywhere. Then
I found that Saxon wouldn't understand '.' as meaning the current
directory. So I used Windows' 'cd' command to get the current
directory and assigned the result to a variable (using 'set'), which
I then passed into the stylesheet for this purpose. It was at this
point that the problem arose.
So, as Andrew indicates, this is a problem specifically with paths
that are generated by Windows itself and have not been entered manually,
and so there is no reasonable alternative that I can see to using
the '=' option in 'set' that allows strings to be substituted.
Helpfully,
Richard.
-----Original Message-----
From: Houghton,Andrew [mailto:houghtoa(_at_)oclc(_dot_)org]
Sent: 11 October 2007 15:48
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] Windows Batchfile calling Saxon -
Confusion of / and \
From: Paul Spencer [mailto:xml-dev-list(_at_)boynings(_dot_)co(_dot_)uk]
Sent: 11 October, 2007 09:49
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--