- 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