- From: <bugzilla@jessica.w3.org>
- Date: Tue, 07 May 2013 11:06:49 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19597 Michael Kay <mike@saxonica.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@saxonica.com --- Comment #12 from Michael Kay <mike@saxonica.com> --- I agree with Christian (comment #10) and disagree with Tim (comment #11). This test is designed to be run by implementations that support the module import feature (as indicated in the dependencies), and which may or may not have the capability to disable the feature. When such an implementation encounters an "import module" it is perfectly entitled to attempt the module import, and because the module import cannot be resolved it is perfectly entitled to report the failure; and once an error has been reported, an implementation is perfectly entitled to report that error and then stop without looking at for further errors. If the module import were not in error, the processor would have to report an error saying that module import is prohibited, but there are two errors here (module import cannot be resolved, and module import not allowed) and I don't think we can demand that the second one takes priority. Furthermore the test metadata contains a comment ("The test must be reported to fail if a different error is returned") which in my view has no force. The general rules apply: reporting a different error code does not cause a test to fail. It's generally a good idea for tests to be designed so they only contain one error. This test doesn't meet that criterion; it would be best to fix it by making the "import module" resolve. (Incidentally, the quoted phrase "must act as though" is a classic pitfall in spec language; I'm always very wary of specifications that use the "act as if" formula. They almost invariably raise questions about which of two conflicting statements in the specification takes precedence. If such constructs are unavoidable, then the provisions they override should acknowledge the conflict, for example "Unless clause 18(b) applies, a module import declaration causes a module to be imported...".) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 7 May 2013 11:06:53 UTC