Michael> This doesn't actually address the UNC question, but I'm
Michael> pretty sure that conclusion when we last discussed it on
Michael> the list was that the correct form (i.e. the one most
Michael> likely to work) was file:////server/file/name - yes, four
Michael> slashes.
Now that surprises me. I was expecting an answer like David Carlisle
gave:
file://server/file/name
Interesting. Note that UNC's use share names to access file systems on servers. But I would agree
that if one would point to c:\foo\bar on machine x, using file://x/c:/foo/bar (or should : be | in
this case?), than pointing to \\x\shareC\foo\bar would be file://x/shareC/foo/bar.. I think...
:-)
Michael> P.S. Does anyone think I ought to allow windows path names in
places where
Michael> the spec requires a URI? I'm disinclined to do it, but it does
give people a
Michael> problem moving to a product that enforces the rules strictly from
one that
Michael> doesn't.
You mean like in xsl:import href attribute? I think not.
My concern is allowing file names on a command line, and converting
them to URLs, which I think you already do with Saxon.
I agree. I would prefer a programming language (Java?) that unifies the way files are addressed. And
the file: protocol (if well described) should be equally well suited or even better to address files
on Windows as UNC, short dos paths or else.
I once had to pass a file: path to a java module to access a file, but had to pass a Windows path to
get the result written to the file system!! Now that's nuts!
Grtz,
Geert