W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2013

[Bug 19597] [QT3TS] prohibit-all-optional-features-2

From: <bugzilla@jessica.w3.org>
Date: Tue, 07 May 2013 11:06:49 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-19597-523-Dx8gT9PS25@http.www.w3.org/Bugs/Public/>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:43 UTC