4215 2007-01-13 22:20:47 +0000 wrong expected output for K2-Literals-8, K2-Literals-9 2007-01-22 05:15:54 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Linux RESOLVED FIXED P2 normal --- 1 per frans.englich martin public-qt-comments oldest_to_newest 13521 0 per 2007-01-13 22:20:47 +0000 The tests K2-Literals-8 K2-Literals-9 test for Really Large floating-point literals. The can optionally fail with FOAR0002. Alternatively, they can evaluate to K2-Literals-8.txt or K2-Literals-9.txt. Both of which contain the incorrect value "true". 13523 1 mike 2007-01-14 16:35:50 +0000 Sorry if I've lost the thread, but where do I look to find tests named K2-Literals-8 or K2-Literals-9? 13526 2 per 2007-01-14 20:31:58 +0000 (In reply to comment #1) > Sorry if I've lost the thread, but where do I look to find tests named > K2-Literals-8 or K2-Literals-9? It's a test that Frans Englich added recently to CVS: Queries/XQuery/Expressions/PrimaryExpr/Literals/K2-Literals-8.xq It's in PublicPagesStagingArea/XQTS_current.zip, and also AdditionalFiles/submission-frans2.zip. 13539 3 mike 2007-01-15 11:22:01 +0000 Thanks. I updated my CVS copy of the test suite but forgot to unzip the XQTS_current.zip file. 13551 4 frans.englich 2007-01-15 16:46:06 +0000 An attempted fix has been committed to CVS, and should be part of XQTS_current.zip. Feel free to verify that the fix is acceptable, and if so, change status to CLOSED. If the attempted fix is not acceptable, reopen this report. If no opinion about this resolution is expressed within two weeks, it will be closed. 13570 5 per 2007-01-16 00:59:00 +0000 (In reply to comment #4) > An attempted fix has been committed to CVS, and should be part of > XQTS_current.zip. Feel free to verify that the fix is acceptable, and if so, > change status to CLOSED. If the attempted fix is not acceptable, reopen this > report. It doesn't like you did the upload right. K2-Literals-8.txt (and other files) are missing from PublicPagesStagingArea/XQTS_current.zip: $ zipinfo PublicPagesStagingArea/XQTS_current.zip|grep K2-Literals-8 -rw-r--r-- 2.0 unx 486 b- defN 15-Jan-07 15:15 Queries/XQuery/Expressions/PrimaryExpr/Literals/K2-Literals-8.xq - but no K2-Literals-8.txt. However, K2-Literals-8.txt is referenced in the XQTSCatalog.xml I extracted from that same .zip. 13571 6 per 2007-01-16 01:23:21 +0000 I guess I should list the missing files: ExpectedTestResults/Expressions/PrimaryExpr/Literals/K2-Literals-8.txt ExpectedTestResults/Expressions/PrimaryExpr/Literals/K2-Literals-9.txt ExpectedTestResults/seqExprTypes/PrologExpr/BaseURIProlog/K2-BaseURIProlog-5.txt 13574 7 frans.englich 2007-01-16 09:18:52 +0000 Here's the catalog entry for K2-Literals-8: <ts:test-case Creator="Frans Englich" is-XPath2="false" name="K2-Literals-8" FilePath="Expressions/PrimaryExpr/Literals/" scenario="standard"> <ts:description>Use a relatively large xs:double literal.</ts:description> <ts:query name="K2-Literals-8" date="2007-01-15+01:00"/> <ts:input-file role="principal-data" variable="input-context">emptydoc</ts:input-file> <ts:output-file role="principal" compare="Ignore">K2-Literals-8.txt</ts:output-file> <ts:expected-error>FOAR0002</ts:expected-error> </ts:test-case> So the output baselines are as follows: * An expected error, FOAR0002 * An ignore baseline. That is, any output is valid. The guidelines reads: "Ignore: no comparison needs to be applied; the result is always true if the implementation successfully executes the test case." So, it makes little sense to open a file for which nothing shall be done for. I agree that that K2-Literals-8.txt is mentioned is confusing, and that it is less confusing with an absent filename. I'll get rid of the dummy name in a future commit. I believe the same reasoning could be applied to the initial comment in this report. For example, K2-Literals-8.txt existed and had the content "true", but was referenced from the catalog as Ignore, and the content shouldn't matter(although it surely isn't pretty to throw files around like that). Is my analysis correct or am I missing something? 13576 8 martin 2007-01-16 10:49:53 +0000 Well, it broke my XQTS-to-our-test-format transformation script as I didn't have explicit code testing on the 'ignore' value for the transformation itself. 13688 9 frans.englich 2007-01-18 15:25:45 +0000 As I see it, it didn't break any driver. The 'Ignore' comparison have been in the catalog for ages. However, I believe there was a period where no tests made use of it, which could explain why we're seeing this discrepancy in the driver. I'm closing this as FIXED, because it to me seems that the tests have been fixed. If this resolution is acceptable, feel free to change status to CLOSED. Otherwise, reopen this report. I will auto-close this report after two weeks, if a reply is absent. 13692 10 per 2007-01-18 19:04:16 +0000 I don't object to closing this bug. Will/have you change the content of the respective <output-file> elements to empty? I think that would be cleaner. It would also be nice to clarify this issue in the testsuite documentation. 13715 11 frans.englich 2007-01-20 10:14:20 +0000 Yes, the content of output-file elements are(or will be, if it's still in my local changes) empty, to avoid confusion. I surely agree it is cleaner. The guidelines says in Comparing Results: "Ignore: no comparison needs to be applied; the result is always true if the implementation successfully executes the test case." If you ask me, that sentence is quite good at explaining what the Ignore comparison means. What changes more specifically do you think would make it better? 13743 12 per 2007-01-22 05:15:54 +0000 It's ok as it is, but it might be a little better with something like: "In this case there is no "expected file", and the contents of the output-file element should be empty." But it's no big deal.