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 catalog documents this test as raising FOAR0002 (numeric overflow). However, the value is not too large to represent as an xs:double (it is around 10^123). It has too many digits to represent precisely as an xs:double, but that's not the same thing. The same applies to K2-Literals-9 K2-Literals-10 is related: it attempts to induce underflow. However, the specification allows 0 to be returned on underflow.
Note the ignore baselines for these tests(8, 9, 10): <ts:output-file role="principal" compare="Ignore"/> The Saxon driver I have doesn't support it(the Ignore method was used in the suite a long time ago, then for a period it wasn't, and now these tests use it again.) I'll change K2-Literals-9 and K2-Literals-8 to actually cause overflow.
Are you suggesting that if a test has an expected-error, and an output-file with compare="Ignore", then this is a signal that expected-error is optional? I'm not sure what result would constitute a failure for such a test.
I'd say that if any baseline matches, the test succeeds. So if the baselines are two error codes A and B, the test passes if either error code A or B is issued. In this case, the test passes if the error code is issued, or if any output is generated. However, it won't pass if it crashes or issues an error code different than what the baseline specifies. So, Ignore refers to XDM-output, not error codes("*" is used for any error code). Sure, there are stronger tests than that one, but from a regression perspective it can be useful to exercise such weird code paths. Of course, such ignore-baselines could be more specific if the test run had as input the implementation defined limits. At least, this is how I personally perceive the test run guidelines, and how many of the other tests are written.
> it won't pass if it crashes or issues an error code > different than what the baseline specifies A system declare a test pass if it generates an error with a different error code. You are not forced to check the codes match.
David, I don't see what makes raising an arbitrary error code ok; the specifications distinguishes between different error codes and the XQTS does too. (How hard one hunts down non conformance on this is another matter though.)
(In reply to comment #5) > David, I don't see what makes raising an arbitrary error code ok; the > specifications distinguishes between different error codes and the XQTS does > too. > > (How hard one hunts down non conformance on this is another matter though.) > see the guidelines at http://www.w3.org/XML/Query/test-suite/Guidelines%20for%20Running%20the%20XML%20Query%20Test%20Suite.html Note that it says "The result of a test is true, if the implementation raises an error. Note that the only requirement is that it raise an error, not that the codes match. When finalising my xq2xsl test submission during CR testing I double checked that with the WG and would have classed my tests as fail if they gave XSLT rather than XQuery errors had I been asked to do so but it was explicitly confirmed that these tests should be classed as pass. See Andrew's reply in http://www.w3.org/Bugs/Public/show_bug.cgi?id=3540#c1
After having adjusted the tests to not be as confused(or at least less confused) about overflow, combined with the explanation of the catalog in #3, I think this report can be attempted to be closed. I think the catalog is correct in CVS, taking into account David's explanation of how the error codes comparison actually works.