This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
4.1.5 Function Calls "overloading is restricted to atomic types with the same quantifier." It's not clear what this means, or how one would "notice" it, given the preceding.
This should be expanded as a clarification of the previous comment. Here is some proposed wording for the paragraph. << Note that this normalization rule depends on the function signatures, which is used to obtained the types of the function parameters (SequenceType1,...SequenceTypen). For user-defined functions, the function signature can be obtained from the XQuery prolog where the function is declared. For built-in functions, the signature is given in the F&O document. For overloaded built-in functions, several signatures may exists, however, because they all correspond to sequences of atomic values, they all result in the same normalization. >> That wording does not rely on the static environment which avoids the cyclicity issue. - Jerome
The XML Query and XSLT WGs have accepted the comment with the fix proposed below. - Jerome
(In reply to comment #1) > > For overloaded built-in functions, several signatures may exists, > however, because they all correspond to sequences of atomic values, > they all result in the same normalization. Given the acceptance of Bug 1580, that sentence should not be necessary. Removing it would completely address the original comment. Actually, it occurs to me that even without the acceptance of 1580, the sentence is unnecessary, as was the quoted sentence in the original comment. That is, 4.1.5/Normalization doesn't (and didn't) need to address "overloaded built-in functions", because calls to those functions cannot occur in pre-normalization queries. Instead, such calls come about as a result of normalizing other (operator/operand) expressions, and those calls do not need to be normalized again, so 4.1.5/Normalization never sees them.
(In reply to comment #1) > > << > Note that this normalization rule depends on the function signatures, > which is used to obtained the types of the function parameters > (SequenceType1,...SequenceTypen). For user-defined functions, the function > signature can be obtained from the XQuery prolog where the function is > declared. For built-in functions, the signature is given in the F&O document. > >> > > That wording does not rely on the static environment which avoids the > cyclicity issue. Presumably you're talking about the circularity I raised in Bug 1577. However, that circularity was: normalization of a function call depends on the expected parameter types which (in the case of overloaded functions) depends on the particular signature used which is determined by the static types of the arguments which is provided by static type analysis of the arguments which is performed on the core-syntax versions of the arguments which results from normalization of the arguments. That is, the circularity was "Normalization depends on Static Type Analysis, which depends on Normalization". The circularity was broken at the former dependency, specifically "the choice of signature depends on the static types of the arguments", by eliminating any choice of signature. Thus, your comment: > That wording does not rely on the static environment which avoids the > cyclicity issue. is inappropriate for a few reasons: (1) The circularity is already broken. (2) Normalization's reliance on the static environment is not something to be avoided. After all, section 3.2.2 tells us that "normalization is always applied in the presence of a static context". (3) Even if you were trying to eliminate that reliance, you can't do it simply by avoiding the words "static environment". That is, to say: > For user-defined functions, the function signature can be obtained > from the XQuery prolog where the function is declared. For built-in > functions, the signature is given in the F&O document. and suggest that the normalization rule has access to this information by some means other than the static environment, that's just silly. Please reinstate the wording "this normalization rule depends on the static environment".
I agree, the issue is resolved by changes resulting from fixes to Bug 1577, which eliminate the choices of signatures in the case of overloaded functions. As a result, there is no problem in reinstating the wording suggested by Michael Dyck. Thanks, - Jerome