This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A number of functions (e.g. parse-json, load-xquery-module, transform, ... are defined to take a map as an argument to define options on how the function behaves. Generally the map is a set of key/value pairs, the keys are strings, and for each defined key name there is a required type for the corresponding value, for example boolean or string. We need to decide whether the supplied value in such an option is converted to the required type using the function conversion rules, or whether the supplied value must actually be an instance of the required type. Currently the way the specs are written, there is no conversion. The only time I've encountered a problem with this is where the required type is a function: for example the fallback function in the options of parse-json and json-to-xml must be of type function(xs:string) as xs:string. Because function coercion is not applied, this makes it invalid, for example, to supply a function whose signature is function(xs:string?) as xs:string? -- because this does not conform to the required type. Supplying functions for these parameters therefore requires much more careful attention to detail, and understanding of the subtyping rules, than is the case when function are supplied directly as arguments of a higher-order function. (Note also, in XQuery -- unlike XSLT -- the function conversion rules are not applied when binding a value to a variable, so a similar problem applies here.)
To take an example of the problem, consider a call that attempts to delete all invalid characters from JSON input by doing: parse-json($in, map{'fallback':function($s){""}}) It turns out this doesn't work, because the function is the wrong type. It has to be written parse-json($in, map{'fallback':function($s as xs:string) as xs:string {""}}) The extra verbiage is all telling the system what it could easily work out for itself... A pragmatic solution might be to relax the required type, so instead of requiring function($s as xs:string) as xs:string the required type becomes function($s as xs:string) as item()* and we then specify what happens dynamically if the returned value isn't a single string. The first call above then becomes legal. There are precedents for this, for example fn:remove() takes xs:integer rather than xs:positiveInteger as the second argument, to allow the function to be called more easily.
The WG decided that (as a matter of convention for design of functions, rather than a built-in language feature) functions that take option parameters should apply a standard set of conventions for how these are handled, and the conventions should include conversion of supplied values to the required type (for a particular entry in the map) using the function conversion rules.
The changes have been applied.