This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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".
Sorry if I've lost the thread, but where do I look to find tests named K2-Literals-8 or K2-Literals-9?
(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.
Thanks. I updated my CVS copy of the test suite but forgot to unzip the XQTS_current.zip file.
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.
(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.
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
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?
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.
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.
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.
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?
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.