Re: [xml] Default Catalog On Windows, Deprecated API

[Igor Zlatkovic <igor zlatkovic com>]

On 14.06.2004 21:55, Daniel Veillard wrote:
>   Yeah, for paths it's an Operating System only issue. If the
> C libraries APIs were (const char * + encoding) then libxml2
> would have to handle encoding at those level, but as it is
> filepaths don't have an encoding, it's just a zero terminated
> array of bytes and we can't do anything at that level IMHO.

Right on Linux, wrong on Windows. I haven't involved myself much with 
these details, but here is what I believe true.

Filesystems used on Linux consider the name of the file as a bunch of 
bytes. They don't interpret them, they just compare them at the byte 
level when they need to. Interpretation is left to the applications in 
userland, including libc.

NTFS filesystem interprets file names on several occasions (DOS names), 
adds lexical information to files (see properties of any file on a XP 
system), and I hear rumors about plans to index the files on the 
filesystem level for faster searching, which would involve a great deal 
of lexical interpretation. NTFS uses UTF-16LE on disc and file names 
must be valid UTF-16LE strings.

On Linux, you have the libc and your program to interpret the file names 
as you please. Mostly you would interpret them as strings from your 
current locale. On Windows, file names are always Unicode and the system 
provides an emulation layer for applications which are not 
Unicode-aware, converting them between your locale and Unicode on the fly.

All that is a theory about the internal functioning, it is nothing 
libxml should be concerned about. Libxml does it the Linux way, passing 
the bunch of bytes to the lower level without interpretation and that is 
only right. At the end, you are right. There is nothing libxml could or 
should do. My thought which started this was a wild one, something that 
could perhaps make sense in a #ifdef _WIN32 block, in most cases not 
even there. I guess I was daydreaming.

Ciao,
Igor