- From: <bugzilla@jessica.w3.org>
- Date: Tue, 04 Jun 2013 15:51:01 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19597 Jonathan Robie <jonathan.robie@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.robie@gmail.com --- Comment #13 from Jonathan Robie <jonathan.robie@gmail.com> --- (In reply to comment #11) > Personal opinion follows. > > The line > > declare option prohibit-feature "module"; > > means that the implementation must act "... as though the feature were not > implemented... " I can't see how an implementation which did not implement > the module feature would attempt to resolve a module, and thus it would > never raise XQST0059. I agree. Here is the wording in the spec: <quote> A require-feature option declaration provides a whitespace-delimited list of named features that must be enabled for the module in which the option declaration occurs; if any declaration requires a feature that the implementation does not support, a static error [err:XQST0120] is raised. A prohibit-feature option declaration provides a list of named features that must not be enabled in the module in which the option declaration occurs; 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]. </quote> Some people are asking for freedom to raise an error due to incorrect use of a prohibited feature. I don't like that - a user who gets error XQST0059 may go off and write a schema, put that in the correct location, and bump into the next error: schemas aren't allowed in this query in the first place. That's not helpful for the user. Also, as Ghislain points out, if a feature is not implemented, raising errors defined by that feature is also not implemented, so XQST0039 does not make sense here. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 4 June 2013 15:51:03 UTC