3883 2006-10-29 10:42:00 +0000 [FS] editorial: 4.1.5 Function Calls / Static Type Analysis 2008-08-31 02:24:26 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Candidate Recommendation All All CLOSED FIXED P2 minor --- 1 jmdyck jmdyck public-qt-comments oldest_to_newest 12650 0 jmdyck 2006-10-29 10:42:00 +0000 4.1.5 Function Calls STA "categories the belong to" s/the/they/ "looking-up" s/-/ / "The following two rules ... by first looking-up the expanded QName for the function, then applying the appropriate set of static typing rules depending on the category in which the function is." That doesn't describe what these two rules do, it describes what the subsequent prose (with the three-way split) does. "check that some signature for the function satisfies the following constraint: the type of each actual argument is a subtype of some type that can be promoted to the type of the corresponding function parameter." Old wording. Change to: "check that the type of each actual argument can be promoted to the type of the corresponding function parameter." "Notice that the static context contains at most one function declaration for each function." Well, strictly speaking, it contains at most one function signature for each (function name, arity) pair. It would be more approriate to say this earlier, after "look up the function in the static environment". "This [the fact that there's at most one signature pertinent to a FunctionCall] is possible since the treatment of overloaded operators is done through a set of specific static typing rules which do not require access to the environment." While it's true that the overloaded fs: functions have special static typing rules, it isn't true that: a) they do not require access to the environment, or b) their special treatment "makes it possible" for statEnv.funcType to map to a single signature. Moreover, they're not really relevant at this point, since the three-way split has already dispatched them to C.2. (This sentence is a leftover, delete it.) 14227 1 jim.melton 2007-02-26 00:20:34 +0000 The fix for this bug does not appear in the Recommendation of 23 January 2007. It will be considered for a future publication (either an Errata document or some possible future version of the specification). 21705 2 jmdyck 2008-08-31 02:24:16 +0000 This issue has been entered as FS erratum E048, and the fix has been committed to the source files for the next edition of the FS document. Consequently, I'm marking this issue resolved-FIXED, and CLOSED.