29684 2016-06-03 14:22:34 +0000 [FO31] options arguments 2016-06-14 15:22:53 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC Windows NT CLOSED WONTFIX P2 normal --- 1 tim mike public-qt-comments oldest_to_newest 126670 0 tim 2016-06-03 14:22:34 +0000 I suggest the options arguments in the following be changed to accept map(*)?, such that the unary version of each function is the same as a call to the binary version with empty sequence as the options argument. This would follow the behaviour of fn:serialize. fn:parse-json($json-text as xs:string?, $options as map(*)) as item()? fn:json-doc($href as xs:string?, $options as map(*)) as item()? fn:json-to-xml( $json-text as xs:string?, $options as map(*)) as document-node()? fn:xml-to-json($input as node()?, $options as map(*)) as xs:string? fn:load-xquery-module($module-uri as xs:string, $options as map(*)) as map(*) 126706 1 tim 2016-06-08 10:09:04 +0000 As requested, I made a list of functions in which an "optional" argument could be made to accept the empty sequence. This list was huge. Additionally, there is also an often-followed convention that foo() is equivalent to foo(.), e.g. fn;node. Furthermore, there are some cases such as adjust-*-to-timezone which already accept empty-sequence in the "optional" argument, but ascribe a particular meaning to it which is different from the single argument version. However, the original request is still sensible and in keeping with fn:serialize. 126763 2 tim 2016-06-14 15:22:27 +0000 The WG decided not to make the change in the interests of stability of the specification.