GNOME Bugzilla – Bug 62456
relative filenames in xsl:include
Last modified: 2009-08-15 18:40:50 UTC
Xsl:include does not work if the stylesheet name entered from command line contains backslashes instead of slashes. The error message is: warning: failed to load external entity "xsl-to-be-included.xsl" compilation error: file c:\path\original-file.xsl line 5 element include xsl:include : unable to load xsl-to-be-included.xsl The file is to be included as follows: <xsl:include href="xsl-to-be-included.xsl"/> and is located in the same directory as original-file.xsl. Changing backslashes on the command line to normal slashed is a workaround to this problem. I'm using libxml2-2.4.6 and libxslt-1.0.5.
Well using URI-References (i.e. / for separator) is definitely a better idea if you start doing XML work. C.f. RFC 2396 and especially the file:// URL scheme. I'm not sure it's really my job to fix this. That would go into a large #if WIN32 #endif section and I don't even have a machine to test this on ! If you feel like providing a patch, I may integrate it, otherwise, well use the / separator. Daniel
Maybe a good solution would be to accept a filename on command line that conforms to local operating system's conventions and first convert to a URI reference. As a user I would expect the program to accept such file names. The naming convention used in xsl:include shloud not be influenced by this.
Yes that's what I had in mind. But this is still a Windows only piece of code, this mean I can't debug it, I won't write it. Daniel
This was discussed again in the mailing list with the Windows maintainer and users. It seems that there is no need to fix the current tools path support and changing the URI-Reference code handling would be a breakage of the RFC-2396 spec, so closed, Daniel