5686 2008-05-14 08:57:30 +0000 K2-Literals-28, K2-Literals-39 2008-06-24 12:44:23 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 mike frans.englich public-qt-comments oldest_to_newest 20088 0 mike 2008-05-14 08:57:30 +0000 In test K2-Literals-28, the literal as written in the source contains the whitespace sequence 20 0D 0D 0D 20 0D 0D 0A The published results appear to expect this to be normalized to 20 0A 0A 0A 20 0A I believe the correct normalization is to 20 0A 0A 0A 20 0A 0A The same problem affects K2-Literals-39 Michael Kay 20089 1 mike 2008-05-14 10:12:44 +0000 The same problem affects tests K2-DirectConOther-50 K2-DirectConOther-52 K2-DirectConOther-54 K2-DirectConOther-66 K2-DirectConOther-68 K2-DirectConOther-69 K2-DirectConOther-70 The tests appear to be written in the belief that a sequence of 0D characters followed by a 0A should be normalized to a single 0A. I think this is incorrect. The XQuery rules are in A2.3 (they both reference the XML 1.0 rules, and paraphrase them, which is unwise, but I think the paraphrase is correct). The XML 1.0 rules are in 2.11. 20097 2 nick 2008-05-15 10:19:51 +0000 I've just looked at the files you mention and the source files I'm getting do not match what you are describing, so for the sources I get: $ od -c -t x1 K2-Literals-28.xq 0000560 a \r \r \r \r \n s t r i n g l 61 20 0d 0d 0d 20 0d 0a 73 74 72 69 6e 67 20 6c $ od -c -t x1 K2-Literals-39.xq 0000600 * : ) \n ' a \r \r \r \r \n s t r 2a 3a 29 0a 27 61 20 0d 0d 0d 20 0d 0a 73 74 72 For those sources I think the current results are correct. What are your file details? I've got: -rw-r--r-- 1 nick mkgroup-l-d 393 Dec 20 17:05 K2-Literals-28.xq -rw-r--r-- 1 nick mkgroup-l-d 414 Jan 24 11:02 K2-Literals-39.xq 20098 3 mike 2008-05-15 10:46:25 +0000 Thanks for the info. The timestamps on my files match (modulo timezone), but the contents don't. I'm seeing in K2-Literals-28 61 20 0d 0d 0d 20 0d 0d 0a 73 74 72 where you have 61 20 0d 0d 0d 20 0d 0a 73 74 72 I guess something (CVS?) has tried to be clever and added a 0d before every 0a. I've just deleted the file and done a CVS update: no change. I notice TortoiseCVS has an option "Sandbox DOS/UNIX" which despite the name apparently controls LF/CRLF endings in text files. It is currently set to "Autodetect (default to DOS)". It's not clear that any of the other options (DOS|UNIX|Autodetect (default to UNIX)) would be any better overall, though they might fix the problems for these files. I don't see an option to treat all files as binary. Perhaps I'll just have to wait until someone builds a new ZIP file. 20099 4 davidc 2008-05-15 11:08:48 +0000 I tried to update my cvs to check but the server is not letting me in any more has the psererver account for anonymous access chaged in recent months? It would probably be best if all the white space sennsitive files (input and results) were checked in as binary cvs admin -kb * from a machine where they are currently right, then CVS won't mangle them on checkout. 20100 5 tim 2008-05-15 12:15:06 +0000 I use TortoiseCVS and have Sandbox set to UNIX. A message pops up saying "cvs: Obsolete --lf option used. Please update your client." but it does actually seem to fix the problem! You may have to delete the offending files to force an update. 20123 6 andrew.eisenberg 2008-05-15 20:29:33 +0000 Mike, you can also get the file you want from the web interface to our CVS repository, http://dev.w3.org/cvsweb/2006/xquery-test-suite/. The specific file you want is http://dev.w3.org/2006/xquery-test-suite/TestSuiteStagingArea/Queries/XQuery/Express ions/PrimaryExpr/Literals/K2-Literals-28.xq. 20134 7 frans.englich 2008-05-16 08:55:21 +0000 Yeah, don't we all just love CVS. The conversion of line endings have been a problem for other tests as well. I marked the baselines for the mentioned tests as binaries, although this is of course a bit of hackish solution. But maybe this fixed at least these tests. Unfortunately CVS has no clean solution for this. Changing the default EOL behavior of the client may also be a solution, as suggested. 20781 8 frans.englich 2008-06-24 12:44:23 +0000 I assume the changes described in #7 fixed it, reopen otherwise.