Merge pull request #1168 from michaelhkay/1166-invalid-options

1166 Clarify rule on invalid option keys
qt4cg · Apr 30, 2024 · 3e9fea2 · 3e9fea2
2 parents b8412e6 + b155961
commit 3e9fea2
Showing 1 changed file with 9 additions and 6 deletions.
diff --git a/specifications/xpath-functions-40/src/xpath-functions.xml b/specifications/xpath-functions-40/src/xpath-functions.xml
@@ -688,10 +688,12 @@ for transition to Proposed Recommendation. </p>'>
                   options in the map that are not described in this specification. These options
                   <rfc2119>should</rfc2119> use values of type <code>xs:QName</code> as the option
                   names, using an appropriate namespace.</p></item>
-               <item><p>If an option is not described in the specification,
-                  if it is not supported by the implementation and if its name is in no namespace,
-                  a type error <errorref spec="FO" class="RG" code="0013"/>
-                  <rfc2119>must</rfc2119> be raised.</p></item>
+               <item><p>If an option is present whose key is not described in the specification, 
+                  then a type error <errorref spec="FO" class="RG" code="0013"/> <rfc2119>must</rfc2119> 
+                  be raised unless either (a) the key is recognized by the implementation, 
+                  or (b) the key is a value of type
+                  <code>xs:QName</code> with a non-absent namespace.</p></item>
+
                <item><p>All entries in the options map are optional, and supplying an empty map has the same
                effect as omitting the relevant argument in the function call, assuming this is permitted.</p></item>
                <item><p>For each named option, the function
@@ -709,8 +711,9 @@ for transition to Proposed Recommendation. </p>'>
                for this error are defined in the specification of each function.</p>
                <note><p>It is the responsibility of each function implementation to invoke this conversion; it
                does not happen automatically as a consequence of the function-calling rules.</p></note></item>
-               <item><p>In cases where an option is list-valued, by convention the value may be supplied
-               either as a sequence or as an array. Accepting a sequence is convenient if the
+               <item><p>In cases where an option is list-valued, by convention the function should accept
+               either a sequence or an array: but this rule applies only if the specification
+               of the option explicitly accepts either. Accepting a sequence is convenient if the
                value is generated programmatically using an XPath expression; while accepting an array 
                allows the options to be held in an external file in JSON format, to be read using
                a call on the <code>fn:json-doc</code> function.</p></item>