W3C home > Mailing lists > Public > public-xml-testsuite@w3.org > April 2004

Re: More encoding problems - japanese test cases

From: Karl Waclawek <karl@waclawek.net>
Date: Thu, 22 Apr 2004 16:15:09 -0400
Message-ID: <004001c428a6$827f27b0$9e539696@citkwaclaww2k>
To: "Richard Tobin" <richard@cogsci.ed.ac.uk>
Cc: <public-xml-testsuite@w3.org>


----- Original Message ----- 
From: "Richard Tobin" <richard@cogsci.ed.ac.uk>
To: <public-xml-testsuite@w3.org>
Cc: "Karl Waclawek" <karl@waclawek.net>
Sent: Thursday, April 22, 2004 11:20 AM


> > Right after the XML declaration there is a sequence (hex):
> > 0x0d 0x0a 0x00 0x0d 0x0a 0x00
> > Should that not be 0x0d 0x00 0x0a 0x00 0x0d 0x00 0x0a 0x00 ?
> 
> I think this is a CVS problem.  The file really contains 0A 00 0A 00,
> and when you checked it out, the OAs were converted to OD OA.
> 
> Presumably the files are not marked as binary in the repository, and
> you are checking them out on a MS Windows machine.
> 
> I suspect this is the cause of the other problems you reported too.

OK, I checked the test suite out again (WinCVS), this time specifying
Unix line breaks. (I consider this a workaround, not a solution)

The results confirm your suspicions.
We were testing with a script written in C# to test the new
SAX.NET parser ports. Before, Expat (for .NET) failed on 18 test cases,
now it fails on only 9:

Script results:
  Files Passed: 2153
  Files Failed: 9
  Files Not Supported: 271

The cases that failed, but are now successful are these:

valid-sa-049
valid-sa-050
valid-sa-051
pr-xml-little
pr-xml-utf-16
weekly-little
weekly-utf-16
utf16b
utf16l

Which are exactly the ones I complained about.

> I seem to recall that this came up before, but no-one dared to run
> the command that would change every file in the repository to be marked
> as binary.

Confirmed to be a good idea. ;-)

Karl
Received on Thursday, 22 April 2004 16:15:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:04 GMT