1580 2005-07-14 04:12:36 +0000 [FS] technical: 4.1.5 Function Calls: complicated by pseudo-functions 2006-10-20 00:00:40 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Last Call drafts All All CLOSED FIXED P2 normal --- 1 jmdyck simeon public-qt-comments oldest_to_newest 4554 0 jmdyck 2005-07-14 04:12:36 +0000 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. 5069 1 jmdyck 2005-07-21 04:25:09 +0000 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. 5251 2 simeon 2005-07-27 15:14:52 +0000 We think this is a good suggestion and we should accept the comment and fix typing rules as suggested. 5261 3 jmdyck 2005-07-28 02:22:03 +0000 (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). 5605 4 simeon 2005-08-31 15:23:52 +0000 The XML Query and XLST WGs have accepted the comment and the suggested fix. - Jerome 9622 5 jmdyck 2006-05-09 05:55:50 +0000 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,...) 9710 6 simeon 2006-05-09 15:07:04 +0000 The comment was not implemented properly in B.2. Fixed the corresponding rules to use the expanded-QName(Type1,...) form. - Jerome