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 "Otherwise, the function signatures matching the function name and arity are retrieved from the static environment." The XQuery and XPath specs both state: "Each function is uniquely identified by its expanded QName and its arity (number of parameters)." So am I correct in thinking that there would be *multiple* signatures only in the cases of the "arithmetic operator pseudo-functions" and the "comparison pseudo-functions"? Is it also true that the "union of atomic types" exceptions in the STA are only relevant to the pseudo-functions? (I.e., for any other call, you'd get the same result if those exceptions weren't there.) If so, then details that are only pertinent to pseudo-functions are being allowed to complicate the normal case. Why? It seems to me that this section would be much improved by banishing those details to B.2.
More explicitly: statEnv.funcType: This should map an (expanded-QName,arity) pair to a single function signature. Change the rules in 4.1.5 appropriately. For the "pseudo-functions", supply a suitably general signature (although it doesn't really matter since they have special STA rules anyhow). 4.1.5 / STA / rule 2: Indicate that 'expanded-QName' is that of a pseudo-function. Move the resulting rule to B.2. 4.1.5 / STA / rule 3: Remove the 'not' premises. B.2 Add these rules: [expanded-Qname is that of a binary pseudo-function] Type1 is not a union of atomic types Type2 is not a union of atomic types statEnv |- Type1 can be promoted to Type1' statEnv |- Type2 can be promoted to Type2' operator type for Type1' and Type2' is Type3' -------------- statEnv |- expanded-QName(Type1, Type2) : Type3' [expanded-Qname is that of a unary pseudo-function] Type1 is not a union of atomic types statEnv |- Type1 can be promoted to Type1' operator type for Type1' is Type3' -------------- statEnv |- expanded-QName(Type1) : Type3' Rewrite the existing B.2 / STA as instances of statEnv |- expanded-QName(Type1, ...) : Type instead of statEnv |- QName(Expr1, ...) : Type (See Bug 1755.) Clarify the interaction/relationship between the rules handling promotion and the rules handling optionality.
We think this is a good suggestion and we should accept the comment and fix typing rules as suggested.
(In reply to comment #1) > > statEnv.funcType: > This should map an (expanded-QName,arity) pair to a single > function signature. Similarly, the domain of dynEnv.funcDefn should be changed to (expanded-QName,arity).
The XML Query and XLST WGs have accepted the comment and the suggested fix. - Jerome
In the CR, B.2 / STA / rule (2|3|4|5|6|7) went from QName(Expr1,...) to expanded-QName(Expr1,...) but not to expanded-QName(Type1,...)
The comment was not implemented properly in B.2. Fixed the corresponding rules to use the expanded-QName(Type1,...) form. - Jerome