This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When prohibit feature is used in a module, the specification states that the implementation must behave as if that feature is not enabled in that module. However, not all aspects of optional features are scoped to a module, and this creates difficulties if a feature is enabled in one module but disabled in another. For example, the schema-aware feature "permits an XDM to contain types other than xs:untyped and xs:untypedAtomic", and it makes no sense to allow this in one module and not in others. Similar problems apply to the serialization feature. Although it's plausible to allow fn:serialize to be called in one module, but not to be available in another module, I would hope that there is no expectation that fn:lookup("fn:serialize") succeeds in one case and fails in the other - that's too much of a burden for implementations to justify any value. I would like to agree the principle that prohibit-feature is only required to disable things that can be detected statically.
We agreed to resolve this as follows. General principle: (1) do not change anything to the optional feature section (2) require-feature raises an error if the product does not support it (unchanged) (3) prohibit-feature raises an error if it can be detected statically that the feature is actually used by the module (validate, module import, dynamic function call, ...). (4) you cannot prohibit static typing or serialization. Schema Aware Feature: allows/prohibits schema import and validate, nothing more or less. Different modules may enable/disable this feature in a given query Static Typing Feature: Fine as written. Module Feature: Only allowed in a main module. Serialization Feature: Require/prohibit is not supported, there is no name for this feature. But it is an optional feature, and support for it is implementation-defined. Higher Order Functions: No change