Coercion rules used to convert function result to expected type

[michaelhkay]

We have separated the rules for static and dynamic function calls, which was necessary because static calls can now use keywords, whereas dynamic calls can't.

The new rules say that the coercion rules are used to convert the result to the expected result type in a dynamic call, but they fail to say that this also happens on a static call.

It would be nicer (and less error prone) if we could combine the rules. Ideally we should define that a static function call F(A, B, C) is equivalent to the dynamic call F#3(A, B, C). This in turn would be easier if we can find a way to extend function items to have optional parameters and to permit keyword arguments.

Note also that the definition of the term "coercion rules" is deficient. It doesn't say what the rules are, it just gives an example of one situation where they are used.

[michaelhkay]

I'm working on the coercion rules, and notice in the XQuery version the rule:

If the function call takes place in a [module]other than the [module] (in which the function is defined, this rule must be satisfied in both the module where the function is called and the module where the function is defined (the test is repeated because the two modules may have different [in-scope schema definitions])

I think this rather bizarre rule is unnecessary because of the rules in 2.3.5:

(a) For every node that has a type annotation, if that type annotation is found in the [in-scope schema definitions] (ISSD), then its definition in the ISSD must be equivalent to its definition in the type annotation.

(b) For a given query, define a participating ISSD as the [in-scope schema definitions] of a module that is used in evaluating the query. If two participating ISSDs contain a definition for the same schema type, element name, or attribute name, the definitions must be equivalent in both ISSDs.

The effect of these rules, I believe is that the types used in different modules must be consistent to the extent that conforming to a type in one module guarantees conforming to the same type in a different module.

[michaelhkay]

The issue has been fixed.