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 text says: "If the supplied options are invalid according to the rules of the ·option parameter conventions·, a dynamic error is raised [err:FOQM0007]." However, the rules for option parameters say "For each named option, the function specification defines a required type for the option value. The value that is actually supplied in the map is converted to this required type using the function conversion rulesXP31. A type error [err:XPTY0004]XP31 occurs if conversion of the supplied value to the required type is not possible, or if this conversion delivers a coerced function whose invocation fails with a type error." So for example, test case <test-case name="fn-load-xquery-module-062"> <description>Checks for an error when calling fn:load-xquery-module but variables option value has wrong type.</description> <created by="Debbie Lockett" on="2015-06-04"/> <module uri="http://www.w3.org/fots/fn/load-xquery-module/valid/module" file="load-xquery-module/valid-module.xqm"/> <test>fn:load-xquery-module("http://www.w3.org/fots/fn/load-xquery-module/valid/module", map{"variables" : "v"})</test> <result> <error code="FOQM0007"/> </result> </test-case> should expect XPTY0004. FOQM007 would only be raised under the condition "A dynamic error occurs if the supplied value after conversion is not one of the permitted values for the option in question: the error codes for this error are defined in the specification of each function." and I don't think such a case applies to fn:load-xquery-module, since the specification doesn't place further constraints on the values of options xquery-version,location-hints, context-item, variables or vendor-options. Thus FOQM0007 is redundant.
The WG accepted the change.
Now fixed.