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 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.
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
The XML Query and XSLT WGs have accepted the comment with the fix, as suggested below, using wording proposed in Bug #1577. - Jerome
What was meant was fixed using the wording in Bug 1578. - Jerome
(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.