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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19597

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |cmsmcq@blackmesatech.com
         Resolution|---                         |FIXED

--- Comment #27 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
The WGs discussed this issue at some length on today's call.  Eventually, we
converged on a view similar to that outlined in comment 15 and comment 16:  we
do not wish to constrain tightly the choice of errors raised by processors
which can support a given feature but which can also behave as if they did not
support it.

We resolved that part of the issue by changing sec. 4.20 paragraph 3 of the
spec, replacing the words

    if any of these QNames corresponds to a feature that the implementation
    supports, it must disable that feature, acting as though the feature 
    were not implemented, or raise a static error [err:XQST0131].

to

    if any of these QNames corresponds to a feature that the implementation 
    supports, it must disable that feature, acting (where possible) as though 
    the feature were not implemented, or raise a static error [err:XQST0131].

This change is to be taken as a clarification of the meaning of "disable that
feature":  a processor that disables a feature should behave as if the feature
were not implemented at all, but is not required to do so when doing so would
entail logical contradiction or other impossibility.  (Those who believe the
old wording did require particular behavior can take this change as a weakening
of the conformance requirement to a recommendation.)

  --------

We also discussed how to deal with the interaction between declarations which
affect namespace bindings and prohibit-feature, as illustrated by Michael Kay's
example in comment 26.  We considered three options:  (1) require that all
processors handle the namespace bindings effected by import schema and import
module, even if these features are not supported; (2) say that option
declarations must not rely on such namespace bindings (or simply that such
namespace bindings are not considered when processing option declarations); (3)
do nothing.

We adopted the third option, largely in view of the fact that the other options
would involve changes to the spec and to implementations (and the second option
would have 1.0 compatibility issues).  We reasoned that the example in comment
26 should always raise an error, and we decided (for reasons already laid out
in this discussion) not to try to prescribe narrowly which error is raised. 
The reasoning should probably be recorded here.

- If a processor is not schema-aware, it will raise an error on the schema
import.

- If a processor is schema-aware and cannot turn schema-awareness off, it will
raise an error on the prohibit-feature declaration.

- If a processor can operate in either fashion, the simplest analysis is to
imagine that it processes the module from top to bottom; seeing the schema
import, it shifts to schema-aware mode, and then sees that schema-awareness is
prohibited; it then backtracks, processes the schema import again, and this
time it raises an error on the schema import.  For processors that don't
actually want to backtrack, this amounts to a requirement that when they
process a schema import, they must remember that they have done so, so that
attempts to prohibit schema-awareness will cause errors to be raised.  (When it
sees a prohibit-feature, the processor must be in a position to raise an error
if it is already in possession of guilty knowledge.)  Other analyses of this
case are also possible, but those on the call all agreed (eventually) that
there is no logically consistent way of handling the example that does not
involve raising one error or another.  Processors must raise an error, but they
do not need to agree on their logical analysis of this conundrum, and thus they
do not need to agree in their error codes.

Accordingly, the WG is closing this issue report (again) and marking it
RESOLVED / FIXED.  

If my reading of the historical record is correct, Michael Kay is the most
recent re-opener of the issue; Michael, if you would, please review the
resolution and indicate your assent by closing the bug, or your dissent by
reopening it again.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 11 June 2013 16:56:29 UTC