Inline functions and dynamic function calls are new in 3.0 so there are no backwards compatibility requirements. Nevertheless, we currently invoke the function conversion rules, and the effect of these rules depends on the setting of XPath 1.0 compatibility mode.

There are a number of difficulties with this:

* it's an unnecessary complication for implementors

* since the setting of XPath 1.0 compatibility mode can vary from one expression to another, the spec needs to be clear about which setting applies (is it the declaration of an inline function, or the point where it is called; and what about partial function application?)

* sometimes the invocation of the function is not in user-written code at all, but within the logic of a higher-order function such as fn:filter or fn:fold-left.

I would therefore propose that XPath 1.0 compatibility mode should apply to the function conversion rules only in the case of traditional "static" function calls.

This can be achieved by changing the start of the first bullet of 3.1.5.2 from "If XPath 1.0 compatibility mode is true and an argument is not of the expected type, then" to "In the case of a static function call for which XPath 1.0 compatibility mode is true, when an argument is not of the expected type,"

Perhaps we also should add a note to emphasize that compatibility mode does not come into play as part of the function conversion rules (a) in dynamic function calls, (b) in converting the result of an inline function to its required type, (c) in partial function application, (d) in implicit function calls that occur when evaluating functions such as fn:map and fn:filter.

(A more radical solution, of course, is to drop XPath 1.0 compatibility mode for XPath 3.0. This proposal isn't intended to prejudge whether that's a good idea.)