29935 2016-10-12 10:12:07 +0000 [FO31] 16.3.1 fn:load-xquery-module (FOQM0007) 2016-10-19 12:57:24 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 tim mike public-qt-comments oldest_to_newest 127748 0 tim 2016-10-12 10:12:07 +0000 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. 127837 1 mike 2016-10-18 15:45:44 +0000 The WG accepted the change. 127851 2 tim 2016-10-19 12:57:05 +0000 Now fixed.