Bug 20275 - [XT3TS] document-2004 to 2006
[XT3TS] document-2004 to 2006
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite
Working drafts
PC Windows NT
: P2 normal
: ---
Assigned To: Abel Braaksma
Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
  Show dependency treegraph
Reported: 2012-12-06 16:35 UTC by Tim Mills
Modified: 2013-12-05 16:38 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2012-12-06 16:35:08 UTC
I'm failing to find the requested document xgespr%C3%A4ch.xml.  I have the test suite checked out onto a Windows file system.  If I run the XQuery

fn:put(<foo />, 'xgespr%C3%A4ch.xml')

it creates a file with a name distinct from the one coming out of Mercurial.

-a---        29/11/2012     11:04         90 xgespräch.xml
-a---        06/12/2012     16:33         44 xgespräch.xml

The filename differs from that used in the old test suite.

I don't know whether Bugzilla will preserve the non-ASCII characters in the above...
Comment 1 Michael Kay 2012-12-06 16:59:09 UTC
I guess there's a lot that can go wrong here, what with differences in filesystems, transmission through Mercurial, etc. Need to think if there's a better way of doing it, e.g. having something in the environment that creates a file with given name and content.
Comment 2 Abel Braaksma 2013-11-23 16:22:40 UTC
There seems to be a fix out for Mercurial in the form of an extension that should be installed on the serverside. The particular files with non-ASCII characters will have to be submitted again to fix the issue.

This is not a Windows, or Linux issue per se. It's caused by the choice of the Mercurial developers. For instance, on Windows they use the non-Unicode file API functions, which results in this mess, on Linux there are other issues. On their Encoding information page, they state that the best solution is either to have all filenames in ASCII-only, or to make sure clients and servers run on the same system (windows server, then only windows clients, linux server, then only linux clients etc). See [2].

For us, that's all bad news. It may be that the fix works, but I doubt whether W3C can, or will install it. The plugin is not supported by Mercurial and is still in beta. 

My suggestion is that we add a feature to create a file, of which the contents can be inlined, which becomes part of the prerequisites of a test. From what I've read, that seems to be the only sure-fire way of fixing this.

[1] http://mercurial.selenic.com/wiki/FixUtf8Extension
[2] http://mercurial.selenic.com/wiki/EncodingStrategy