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 specification makes provision for a processor to disable a feature which it supports in response to a prohibit-feature declaration, but there is no corresponding provision for a processor to enable a feature in response to a require-feature declaration which it supports but which is not enabled by default. In general, this isn't a problem. Most optional features do 'no harm' if enabled, I.e. enabling a feature will not cause the failure of query to compile. A notable exception is the static typing feature. A processor which supports (has an implementation of) the static typing feature might wish to operate with the feature disabled by default, since most queries are likely to fail static type checking. It would be enabled expliitly with a require-feature declaration. It would be unreasonable to expect library authors to include an explicit prohibition of the static typing feature.
Ghislain has proposed: If a processor that normally does not support feature A encounters a query that has a require-feature option declaration on this feature A, it must do one of the following: - Process the module using the semantics of this specification with feature A's being supported. - Raise a static error [err:XQST0120].
The Working Group has agreed to the following editorial clarification: A require-feature option declaration provides a list of named features that must be enabled for the module in which the option declaration occurs; if any declaration requires a feature, it must enable that feature, or raise a static error [err:XQST0120] .
I will also change "it" to "the processor" for the sake of clarity: A require-feature option declaration provides a list of named features that must be enabled for the module in which the option declaration occurs; if any declaration requires a feature, the processor must enable that feature or raise a static error [err:XQST0120]. In addition, I will provide definitions for "enable", "disable", and "support", and improve the error code description.