This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21717 - Not used: XQST0124
Summary: Not used: XQST0124
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-16 13:21 UTC by Christian Gruen
Modified: 2013-06-04 16:39 UTC (History)
0 users

See Also:


Attachments

Description Christian Gruen 2013-04-16 13:21:51 UTC
Error code XQST0124 is not used anywhere in the current XQ30 specification. It states that

  "It is a static error if the name of a feature in require-feature or prohibit-feature is not recognized by the implementation."

Instead, the description of XQST0123 is referenced once:

  "It is a static error if the name of a feature in require-feature is not recognized by the implementation."

Next, there seems to be no dedicated error code for options in the "http://www.w3.org/2012/xquery" namespace. Maybe one of the two above was supposed to fill this gap?
Comment 1 Jonathan Robie 2013-05-14 15:34:34 UTC
This is no longer in the internal XQuery 3.0 text. I checked in a query that looks for unused error codes or references to error codes that do not exist, and removed these.
Comment 2 Christian Gruen 2013-05-14 18:04:05 UTC
Thanks for the removal.

I believe that it still needs to be clarified what is going to happen if an option in the default options namespace ("http://www.w3.org/2012/xquery") is unknown. An example:

  declare option unknown "x"; ()

Maybe XQST0124 could be used for that case?
Comment 3 Jonathan Robie 2013-06-04 15:18:49 UTC
(In reply to comment #2)
> Maybe XQST0124 could be used for that case?

Sounds good to me.
Comment 4 Jonathan Robie 2013-06-04 16:39:08 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Maybe XQST0124 could be used for that case?
> 
> Sounds good to me.

The Working Group agrees. I will change this in the spec.