1577 2005-07-14 04:09:35 +0000 [FS] technical: 4.1.5 Function Calls: Normalization 2005-09-06 12:58:53 +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 4551 0 jmdyck 2005-07-14 04:09:35 +0000 4.1.5 Function Calls Normalization "Note that this normalization rule depends on the static environment containing function signatures" Specifically, the SequenceTypei in the rule's RHS presumably come from one of the function signatures in statEnv.funcType. But which one? It seems to me that you need to do Static Type Analysis, which (a) might find more than one valid signature; and (b) operates on instances of the Core syntax, which requires that we first normalize the FunctionCall, and so we have a circularity. 4930 1 simeon 2005-07-19 21:20:28 +0000 The way to break the circularity is that you do not really need static typing. You can just rely on the actual signature declared for the function. In the case of F&O overloaded functions, there may be multiple signatures but they are always for atomic types or sequences of atomic types and this results in the same normalization whichever signature you choose. This should probably be indicated more clearly in the document. - Jerome 5603 2 simeon 2005-08-31 15:21:26 +0000 The XML Query and XSLT WGs have accepted the comment with the fix, as suggested below, using wording proposed in Bug #1577. - Jerome 5630 3 simeon 2005-08-31 23:27:57 +0000 What was meant was fixed using the wording in Bug 1578. - Jerome 5634 4 jmdyck 2005-09-01 00:27:44 +0000 (In reply to comment #1) > > The way to break the circularity is that you do not really need static > typing. You can just rely on the actual signature declared for the function. Sure, *now*. The acceptance of Bug 1580 means that the original "But which one?" question now goes away. Or maybe it was never a valid question; see Bug 1578 comment #3. > In the case of F&O overloaded functions, there may be multiple signatures but > they are always for atomic types or sequences of atomic types and this results > in the same normalization whichever signature you choose. Actually, for different SequenceType <: xdt:anyAtomicType*, []_Convert(SequenceType) *does* result in different normalizations, since the choice of SequenceType constrains the choice of PrototypicalValue. However, that should now be a moot point.