RE: [xsl] Windows Batchfile calling Saxon - Confusion of / and \

["Kerry, Richard" <richard.kerry@xxxxxxxxxxx>]

> 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@xxxxxxxx]
> Sent: 11 October 2007 15:48
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Windows Batchfile calling Saxon -
> Confusion of / and \
>
> > 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.